About Kubernetes Role-Based Access Control and the Operator
Kubernetes supports role-based access control (RBAC), which allows containers to be bound to roles which give them permissions to operate on various resources. This topic aims to give a general overview of RBAC in the context of deploying the Operator and managing Couchbase Server clusters.
RBAC is enabled by default in Kubernetes 1.10+, so you will need to take RBAC into consideration when planning a deployment. The system is flexible enough to meet the challenges of most use-cases, but that flexibility can sometimes create confusion.
For a full explanation of how RBAC works in Kubernetes, refer to the official Kubernetes documentation.
A role essentially maps a name to a set of permissions that a user or service is allowed to perform on the cluster. Roles can be scoped to the entire cluster with the
ClusterRole resource type, or to a specific namespace with the
Role resource type.
The key distinction is that cluster-scoped roles can be specified once and used in any name space, whereas namespace-scoped roles have to be defined in each name space they are used in. Another consideration is that you need cluster administration privileges to install cluster roles, while namespace-scoped roles can be created by a user with sufficient privileges.
The Couchbase Autonomous Operator is currently scoped to a namespace and needs access to various resources within that namespace in order to function correctly. The resources required by the Operator are:
The Operator has the ability to automatically install the custom resource definition (CRD) (defining the
CouchbaseClusterresource type). This is a cluster-level operation. For more information, refer to the Operator configuration documentation.
The Operator watches for changes to cluster resources and preforms the necessary steps to create a cluster according to the configuration that is defined in the cluster specification.
The Operator needs to be able to create and delete pods to deploy and scale the Couchbase Server cluster, as well as perform auto-healing activities.
The Operator needs to create services in order to generate DNS names that are used to address pods, as well as create SRV records for service discovery.
The Operator creates an endpoint resource in order to ensure that no more than one instance is managing clusters at any one time.
The Operator will raise events that are associated with a
CouchbaseClusterresource, which can be used to synchronize external operations or raise alerts.
The Operator consumes cluster passwords and private keys from secrets. Secrets can be securely managed by a separate user from that which is controlling the cluster, giving isolation for security compliance purposes.
The Operator needs to be able to claim persistent volumes when server pods are using the persistent storage option.
The Operator needs to be able to monitor the status of a persistent volume claim.
The Operator needs to verify that the requested storage class exists before claiming a persistent volume.
apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: couchbase-operator rules: - apiGroups: - couchbase.com resources: - couchbaseclusters verbs: - "*" - apiGroups: - storage.k8s.io resources: - storageclasses verbs: - "get" - apiGroups: - apiextensions.k8s.io resources: - customresourcedefinitions verbs: - "*" - apiGroups: - "" resources: - pods - services - endpoints - persistentvolumeclaims - events - secrets verbs: - "*" - apiGroups: - "" resources: - persistentvolumes verbs: - "get" - "watch" - apiGroups: - apps resources: - deployments verbs: - "*"
You may improve security and resilience by running the Operator and the Couchbase Server clusters in an isolated namespace. This will restrict the resources that the Operator potentially has access to to only those that are defined in that namespace. The
An end user also needs a separate set of permissions in order to create the Operator and Couchbase Server clusters. These are:
The user needs to be able to create a deployment that contains the Operator container. This also allows access to logs for monitoring the deployment.
The user needs to be able to create, modify, and delete the Couchbase Server cluster objects that are consumed by the Operator. This also gives access to the cluster description, which contains current state and event information.
These are essentially the same and identify a person and service, respectively. The Operator should run under a service account. When defining the Operator deployment manifest, the named service account you have created for the Operator must be defined in the pod specification template.
Role bindings act as the glue between roles and accounts. There are two variants with different scoping rules. The
RoleBinding resource type may reference either a
ClusterRole or a plain
Role, and grants those permissions to a user, service account, or group in a specific namespace. A
ClusterRoleBinding resource grants permissions to an entity at the cluster level; it is unscoped, meaning that those permissions apply to any namespace.
apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: couchbase-operator-binding-my-namespace roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: couchbase-operator-role subjects: - kind: ServiceAccount name: couchbase-operator namespace: my-namespace
It is recommended that a