--- title: Operator RBAC Settings pubDate: 2026-08-17T09:53:44.266Z antora: editUrl: https://github.com/couchbase/docs-operator/edit/release/2.8/modules/ROOT/pages/reference-operator-rbac.adoc xref: xref:2.8@operator::reference-operator-rbac.adoc[] --- [Consult the llms.txt file for a full list of contents](/llms.txt) [View original HTML](/operator/2.8/reference-operator-rbac.html) # 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](https://kubernetes.io/docs/reference/access-authn-authz/authorization/). 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 Kubernetes 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_: `get`, `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_: `get`, `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_: `get`, `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` > [!IMPORTANT] > The Operator does not need `pods/exec` permissions to run. However, the [cao](tools/cao.md) tool — specifically the [\--collectinfo](tools/cao.md#cao-collect-logs) option — _does_ require `pods/exec` permissions. It needs these permissions in order to execute log collection scripts and run the `cbcollect_info` command locally on each pod belonging to a Couchbase cluster. > > If this is not acceptable, then please refer to [Couchbase Server Logging](concept-couchbase-logging.md) for additional options that ensure log availability (such as [log forwarding](concept-couchbase-logging.md#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](concept-kubernetes-upgrade.md). 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_: `get`, `list`, `watch`, `create`, `update`, `delete` > [!TIP] > 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 `NetworkPolicy` resource can also be used to further restrict access to the clusters at the network level.