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.

couchbaseclusters

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.

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.

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.

endpoints

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

events

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

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.

persistentvolumeclaims

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

persistentvolumes

The Operator needs to be able to monitor the status of a persistent volume claim.

storageclasses

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 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.