A newer version of this documentation is available.

View Latest

About Kubernetes Role-Based Access Control and the Operator

    +

    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.

    Roles

    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. Another consideration is that you need cluster administration privileges to install cluster roles, while namespace-scoped roles can be created by a user with sufficient privileges.

    Operator Role Requirements

    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:

    customresourcedefinitions

    The Operator has the ability to automatically install the custom resource definition (CRD) (defining the CouchbaseCluster resource type). This is a cluster-level operation. For more information, refer to the Operator configuration documentation.

    couchbaseclusters

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

    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.

    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.

    endpoints

    The Operator creates an endpoint resource in order to ensure that no more than one instance is managing clusters at any one time.

    events

    The Operator will raise events that are associated with a CouchbaseCluster resource, which can be used to synchronize external operations or raise alerts.

    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.

    persistentvolumeclaims

    The Operator needs to be able to claim persistent volumes when server pods are using the persistent storage option.

    persistentvolumes

    The Operator needs to be able to monitor the status of a persistent volume claim.

    storageclasses

    The Operator needs to verify that the requested storage class exists before claiming a persistent volume.

    apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: ClusterRole
    metadata:
      name: couchbase-operator
    rules:
    - apiGroups:
      - couchbase.com
      resources:
      - couchbaseclusters
      verbs:
      - "*"
    - apiGroups:
      - storage.k8s.io
      resources:
      - storageclasses
      verbs:
      - "get"
    - apiGroups:
      - apiextensions.k8s.io
      resources:
      - customresourcedefinitions
      verbs:
      - "*"
    - apiGroups:
      - ""
      resources:
      - pods
      - services
      - endpoints
      - persistentvolumeclaims
      - events
      - secrets
      verbs:
      - "*"
    - apiGroups:
      - ""
      resources:
      - persistentvolumes
      verbs:
      - "get"
      - "watch"
    - apiGroups:
      - apps
      resources:
      - deployments
      verbs:
      - "*"
    You may improve security and resilience by running the Operator and the Couchbase Server clusters in an isolated namespace. This will restrict the resources that the Operator potentially has access to to only those that are defined in that namespace. The NetworkPolicy resource can also be used to restrict access to the clusters at the network level.

    User Role Requirements

    An end user also needs a separate set of permissions in order to create the Operator and Couchbase Server clusters. These are:

    deployments

    The user needs to be able to create a deployment that contains the Operator container. This also allows access to logs for monitoring the deployment.

    couchbaseclusters

    The user needs to be able to create, modify, and delete the Couchbase Server cluster objects that are consumed by the Operator. This also gives access to the cluster description, which contains current state and event information.

    Users and Service Accounts

    These are essentially the same and identify a person and service, respectively. The Operator should run under a service account. When defining the Operator deployment manifest, the named service account you have created for the Operator must be defined in the pod specification template.

    Role Bindings

    Role bindings act as the glue between roles and accounts. There are two variants with different scoping rules. The RoleBinding resource type may reference either a ClusterRole or a plain Role, and grants those permissions to a user, service account, or group in a specific namespace. A ClusterRoleBinding resource grants permissions to an entity at the cluster level; it is unscoped, meaning that those permissions apply to any namespace.

    apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: ClusterRoleBinding
    metadata:
      name: couchbase-operator-binding-my-namespace
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: couchbase-operator-role
    subjects:
    - kind: ServiceAccount
      name: couchbase-operator
      namespace: my-namespace
    It is recommended that a RoleBinding be used to grant permissions to the Operator on a per-namespace basis in order to restrict access to the minimum number of resources necessary, which helps improve security, resilience, and performance.