--- title: Couchbase User RBAC pubDate: 2026-08-17T09:53:44.266Z antora: editUrl: https://github.com/couchbase/docs-operator/edit/release/2.8/modules/ROOT/pages/concept-user-rbac.adoc xref: xref:2.8@operator::concept-user-rbac.adoc[] --- [Consult the llms.txt file for a full list of contents](/llms.txt) [View original HTML](/operator/2.8/concept-user-rbac.html) # Couchbase User RBAC > The Couchbase Kubernetes Operator manages Couchbase Role-Based Access Control (RBAC) for the authorization of administrative users and groups. ## [](#overview)Overview Users are created when a `CouchbaseUser` resource is bound to one or more `CouchbaseGroup` resources using a `CouchbaseRoleBinding` resource. The `CouchbaseGroup` resource contains a set of roles that are to be applied to one or more users. ![user binding default](_images/user-binding-default.png) Figure 1\. Basic User Role Binding The Kubernetes Operator only creates users that are bound to groups. Therefore, all three resources are required in order to create an authorized user. ## [](#user-role-binding)User Role Binding A `CouchbaseRoleBinding` resource can bind multiple users to a single group. This model is similar to Kubernetes RBAC which allows multiple service accounts to inherit roles from a single resource. Separating user resources in this manner allows role definitions to easily be shared by multiple users. Consider the following example that creates user accounts for a developer and security admin with overlapping roles. ![multi user binding example](_images/multi-user-binding-example.png) Figure 2\. Shared User Roles In the diagram above, two users are created with the following privileges: | Role | Privileges | | -------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **Application Developer** | **data\_reader+writer:** Read/write access to data on all buckets **replication\_admin:** XDCR and web console access | | **Security Administrator** | **security\_admin:** Management of user roles **replication\_admin:** XDCR and bucket data access | ## [](#managing-groups)Managing Groups The `CouchbaseGroup` represents a collection of administrative and bucket roles which can be applied to users. There is a direct association between the `CouchbaseGroup` resource and [Couchbase Server RBAC groups](../../server/current/learn/security/authorization-overview.md) such that Couchbase Server RBAC groups are created and deleted when corresponding `CouchbaseGroup` resources are created and deleted. Whenever users are bound to a group, the Kubernetes Operator ensures that the corresponding Couchbase Server RBAC group exists with the requested roles, and then proceeds to add the requested users to the group. ### [](#setting-roles)Setting Roles Roles within a `CouchbaseGroup` resource can be added, removed, or changed. Users only need to be bound once, and will automatically inherit any future changes to the roles in the group. By default, bucket roles provide a user with access to all buckets. Buckets resources can be specified under the buckets property of each role, This will add a role for each bucket specified. The following example demonstrates how to restrict data writing to the default bucket, while allowing the user to read from any bucket. ```yaml apiVersion: couchbase.com/v2 kind: CouchbaseGroup metadata: name: datarole spec: roles: - name: data_reader - name: data_writer buckets: resources: - name: default kind: CouchbaseBucket ``` In versions Couchbase Server greater than 7.0.0, bucket roles can be specified for buckets, scopes and collections. In Couchbase Server versions before 7.0.0, these settings will be ignored. The following example demonstrates how to restrict data writing to the default bucket, scope and collection, while allowing the user to read from all scopes and collections within the default bucket. ```yaml apiVersion: couchbase.com/v2 kind: CouchbaseGroup metadata: name: datarole spec: roles: - name: data_reader buckets: resources: - name: default kind: CouchbaseBucket - name: data_writer buckets: resources: - name: default kind: CouchbaseBucket scopes: resources: - name: default kind: CouchbaseScope collections: resources: - name: default kind: CouchbaseCollection ``` Multiple Buckets, Scopes and Collections can be specified. However, `CouchbaseScopeGroup` and `CouchbaseCollectionGroup` can also be utilized to create roles for many scope and collection combinations. ### [](#referencing-ldap-groups)Referencing LDAP Groups Couchbase Server provides LDAP integration which allows external user authentication. The Kubernetes Operator can be used to enable this functionality when an `ldapGroupRef` is specified within the `CouchbaseGroup` resource. ```yaml apiVersion: couchbase.com/v2 kind: CouchbaseGroup metadata: name: datarole spec: ldapGroupRef: cn=mygroup,ou=Groups,dc=example,dc=com roles: - name: cluster_admin ``` The example above demonstrates the creation of a Couchbase Server RBAC group which grants the `cluster_admin` role to all LDAP users within the reference group. Note that you'll need to have LDAP connectivity configured in the `CouchbaseCluster` resource in order use this functionality. ## [](#managing-users)Managing Users A user is created when it is bound to group. A user is also deleted whenever its corresponding `CouchbaseUser` resource is deleted, or if it is no longer bound to any groups. Therefore, the deletion of a `CouchbaseGroup` or `CouchbaseRoleBinding` resource may result in user deletion when doing so results in the user being unbound from a group. The reason why unbound users are deleted is because there are no clear privileges to apply to the user. ### [](#label-selection)Label Selection If you have more than one `CouchbaseCluster` resource deployed in the same namespace, you'll need to use [resource label selection](concept-label-selection.md) to ensure that users and groups get created on the correct cluster. Like with other Couchbase custom resources, this means specifying a label for RBAC resources which matches the corresponding label selector of the `CouchbaseCluster` resource that you want the resources aggregated to. It's recommended that you start by adding a label selector to the `CouchbaseCluster` resource. ```yaml apiVersion: couchbase.com/v2 kind: CouchbaseCluster metadata: name: my-cluster spec: security: rbac: managed: true selector: matchLabels: cluster: my-cluster ``` The `CouchbaseCluster` resource configuration above will only select `CouchbaseUser` and `CouchbaseGroup` resources that are labeled with `cluster: my-cluster`. ```yaml --- apiVersion: couchbase.com/v2 kind: CouchbaseUser metadata: name: my-user labels: cluster: my-cluster --- apiVersion: couchbase.com/v2 kind: CouchbaseGroup metadata: name: my-group labels: cluster: my-cluster ``` Note that `CouchbaseRoleBinding` resources don't support labels and don't directly utilize label selection. Instead, the Kubernetes Operator looks at the names of the users and groups specified in the `CouchbaseRoleBinding` resource. If those names match the `CouchbaseUser` and `CouchbaseGroup` resources that are both being selected by the same cluster, then they will be bound together. Therefore, so long as the `CouchbaseUser` and `CouchbaseGroup` resources have the same label, the users and groups specified in the `CouchbaseRoleBinding` resource will be bound together. > [!NOTE] > Users and groups must match the labels of the same cluster when being bound together, otherwise a scheduling conflict will occur if one cluster is only selecting a user but not selecting the group it belongs to. #### [](#example-label-selection)Example Label Selection The following diagram shows an example of users and groups partitioned across a multi-cluster deployment. ![user label example](_images/user-label-example.png) Figure 3\. User and Group Selection Across Clusters In the example above, the individual users are each selected by different clusters, and each bound to cluster-specific groups. However, each user is also bound to a shared XDCR group that is selected by both clusters. ## [](#related-links)Related Links * **How-to guide:** [Couchbase User RBAC](howto-guide-couchbase-user-rbac.md)