Please use the form below to provide your feedback. Because your feedback is valuable to us, the information you submit in this form is recorded in our issue tracking system (JIRA), which is publicly available. You can track the status of your feedback using the ticket number displayed in the dialog once you submit the form.

A newer version of this documentation is available.

View Latest

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, the cao tool — specifically the --collectinfo 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 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 NetworkPolicy resource can also be used to further restrict access to the clusters at the network level.