Appendix C. Role-Based Access Control (RBAC)
When the Operator SDK generates an Operator project (regardless of whether it is a Helm, Ansible, or Go-based Operator), it creates a number of manifest files for deploying the Operator. Many of these files grant permissions to the deployed Operator to perform the various tasks it does throughout its lifetime.
The Operator SDK generates three files related to Operator permissions:
- deploy/service_account.yaml
-
Instead of authenticating as a user, Kubernetes provides a programmatic authentication method in the form of service accounts. A service account functions as the identity for the Operator pod when making requests against the Kubernetes API. This file simply defines the service account itself, and you do not need to manually edit it. More information on service accounts is available in the Kubernetes documentation.
- deploy/role.yaml
-
This file creates and configures a role for the service account. The role dictates what permissions the service account has when interacting with the cluster APIs. The Operator SDK generates this file with extremely wide permissions that, for security reasons, you will want to edit before deploying your Operator in production. In the next section we explain more about refining the default permissions in this file.
- deploy/role_binding.yaml
-
This file creates a role binding, which maps the service account to the role. You do not need to make any changes to the generated file.
Fine-Tuning the Role
At its most basic level, a role maps resource types to the actions (known as “verbs” in the role resource terminology) a user or service account may take on resources of those types. For example, the following role grants view (but not create or delete) permissions for deployments:
-apiGroups:["apps"]resources:["deployments"]verbs:["get","list","watch"]
Since the Operator SDK does not know the extent to which your Operator will need to interact with the cluster, the default role allows all actions on a variety of Kubernetes resource types. The following snippet, taken from an SDK-generated Operator project, illustrates this. The * wildcard allows all actions on the given resources:
...-apiGroups:-""resources:-pods-services-endpoints-persistentvolumeclaims-events-configmaps-secretsverbs:-'*'-apiGroups:-appsresources:-deployments-daemonsets-replicasets-statefulsetsverbs:-'*'...
Not surprisingly, it is considered a bad practice to grant such open and wide-reaching permissions to a service account. The specific changes you should make vary depending on the scope and behavior of your Operator. Generally speaking, you should restrict access as much as possible while still allowing your Operator to function.
For example, the following role snippet provides the minimal functionality needed by the Visitors Site Operator:
...-apiGroups:-""resources:-pods-services-secretsverbs:-create-list-get-apiGroups:-appsresources:-deploymentsverbs:-create-get-update...
Full details on configuring Kubernetes roles are outside the scope of this book. You can find more information in the Kubernetes RBAC documentation.