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

    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/couchbaseroles
    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

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

    pods/exec

    The operator needs access to execute commands on Couchbase Server pods in order to flag that the pod is ready. This allows orchestration of automatic Kubernetes upgrades.

    Required Permissions: create

    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

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

    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

    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

    batch/cronjobs

    The Operator needs to be able to create and update cron jobs in order to schedule regular backups. 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

    batch/jobs

    The operator needs to be able to create jobs in order to create a restore of a backup. 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

    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.