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.

Roles

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.

Operator Role Requirements

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:

customresourcedefinitions

The Operator has the ability to automatically install the custom resource definition (CRD) (defining the CouchbaseCluster resource type). This is a cluster-level operation. For more information, refer to the Operator configuration documentation.

Required Permissions: get, create

couchbaseclusters

The Operator lists available Couchbase clusters to manage, 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 also updates the couchbase cluster status to reflect cluster state.

Required Permissions: get, list, watch, update

pods

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.

Required Permissions: get, list, watch, create, update, delete

pods/exec

The operator needs access to execute commands on Couchbase Server pods in order to flag that the pod is ready. This allows orchestration of automatic Kubernetes upgrades.

Required Permissions: create

services

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.

Required Permissions: get, list, watch, create, update, delete

endpoints

The Operator creates an endpoint resource in order to ensure that no more than one instance is managing clusters at any one time.

Required Permissions: get, list, watch, create, update, delete

events

The Operator will raise events that are associated with a CouchbaseCluster resource, which can be used to synchronize external operations or raise alerts.

Required Permissions: create, patch

secrets

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.

Required Permissions: get

persistentvolumeclaims

The Operator needs to be able to claim persistent volumes when server pods are using the persistent storage option.

Required Permissions: get, list, watch, create, update, delete

poddisruptionbudgets

The Operator need to be able to create and update pod disruption budgets to allow orchestration of automatic Kubernetes upgrades.

Required Permissions: get, create, delete

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: couchbase-operator
rules:
- apiGroups:
  - couchbase.com
  resources:
  - couchbaseclusters
  verbs:
  - get
  - list
  - watch
  - update
- apiGroups:
  - ""
  resources:
  - pods
  - services
  - endpoints
  - persistentvolumeclaims
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - delete
- apiGroups:
  - ""
  resources:
  - pods/exec
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - get
- apiGroups:
  - policy
  resources:
  - poddisruptionbudgets
  verbs:
  - get
  - create
  - delete
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 NetworkPolicy resource can also be used to restrict access to the clusters at the network level.

User Role Requirements

An end user also needs a separate set of permissions in order to create the Operator and Couchbase Server clusters. These are:

deployments

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.

couchbaseclusters

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.

Users and Service Accounts

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

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 RoleBinding be used to grant permissions to the Operator on a per-namespace basis in order to restrict access to the minimum number of resources necessary, which helps improve security, resilience, and performance.