Operator RBAC Settings
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.
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:
- couchbase.com/couchbaseclusters
- couchbase.com/couchbaseclusters/finalizers
-
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
- couchbase.com/couchbasebuckets
- couchbase.com/couchbaseephemeralbuckets
- couchbase.com/couchbasememcachedbuckets
- couchbase.com/couchbasereplications
- couchbase.com/couchbaseusers
- couchbase.com/couchbasegroups
- couchbase.com/couchbaserolebindings
- couchbase.com/couchbasebackups
-
The Operator logically combines
CouchbaseCluster
resources with these resources in order to manage a Couchbase cluster. The Operator locally caches these resources, so needs to list them to get an initial set, and watch for changes to observe updates.Required Permissions:
list
,watch
- couchbase.com/couchbasebackuprestores
-
The Operator needs to be able to see restores in order to provision jobs that will execute them. The Operator locally caches these resources, so needs to list them to get an initial set, and watch for changes to observe updates. It also garbage collects restores on success, so needs permission to delete them.
Required Permissions:
list
,watch
,delete
- couchbase.com/couchbaseautoscalers
-
The Operator needs to be able to create and delete autoscaler endpoints to provide an interface with the Kubernetes horizontal pod autoscaler (HPA).
Required Permissions:
list
,watch
,create
,update
,delete
- couchbase.com/couchbaseautoscalers/status
-
The Operator needs to be able to update autoscaler status to communicate cluster state with the HPA.
Required Permissions:
update
- pods
- pods/status
-
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. Pod readiness is communicated to Kubernetes with pod readiness gates, requiring access to the pod status conditions. The Operator locally caches these resources, so needs to list them to get an initial set, and watch for changes to observe updates.
Required Permissions:
get
,list
,watch
,create
,update
,delete
,patch
The Operator does not need
pods/exec
permissions to run. However, thecao
tool — specifically the--collectinfo
option — does requirepods/exec
permissions. It needs these permissions in order to execute log collection scripts and run thecbcollect_info
command locally on each pod belonging to a Couchbase cluster.If this is not acceptable, then please refer to Couchbase Server Logging for additional options that ensure log availability (such as log forwarding).
- 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. The Operator locally caches these resources, so needs to list them to get an initial set, and watch for changes to observe updates.
Required Permissions:
get
,list
,watch
,create
,update
,delete
,patch
- 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:
list
,create
,update
- 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. The Operator also uses secrets to cache persistent state about a Couchbase cluster, such as passwords and keys that are not exposed by the Couchbase API, but are required to detect modification and trigger rectification. The Operator locally caches these resources, so needs to list them to get an initial set, and watch for changes to observe updates.
Required Permissions:
get
,list
,watch
,create
,update
- persistentvolumeclaims
-
The Operator needs to be able to claim persistent volumes when server pods are using the persistent storage option. The Operator locally caches these resources, so needs to list them to get an initial set, and watch for changes to observe updates.
Required Permissions:
get
,list
,watch
,create
,update
,delete
,patch
- policy/poddisruptionbudgets
-
The Operator need to be able to create and update pod disruption budgets to allow orchestration of automatic Kubernetes upgrades. The Operator locally caches these resources, so needs to list them to get an initial set, and watch for changes to observe updates.
Required Permissions:
get
,list
,watch
,create
,delete
- configmaps
-
The Operator locally caches these resources, so needs to list them to get an initial set, and watch for changes to observe updates.
Required Permissions:
get
,create
,update
,delete
- batch/jobs
- batch/cronjobs
-
The Operator needs to be able to create and update jobs and cron jobs in order to schedule regular backups and restore data. The Operator locally caches these resources, so needs to list them to get an initial set, and watch for changes to observe updates.
Required Permissions:
list
,watch
,create
,update
,delete
- couchbase.com/couchbaseautoscalers
-
The operator needs to be able to create, update, and delete these resources to propagate changes received from the
HorizontalPodAutoscaler
. The Operator locally caches these resources, so needs to list them to get an initial set, and watch for changes to observe updates.Required Permissions:
list
,watch
,create
,update
,delete
You may improve security and resilience by running the Operator and a single Couchbase Server cluster in an isolated namespace.
This will restrict the resources that the Operator and support tools have access to.
The |