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

Authorization

      +
      For authorizing users, Couchbase Server provides Role-Based Access Control.

      Role-Based Access Control

      Couchbase provides Role-Based Access Control (RBAC), in which access privileges are assigned to fixed roles; which are in turn assigned to users (each of which may be an administrator or an application) either directly; or indirectly, by means of user-groups.

      Couchbase Server Enterprise Edition provides RBAC with multiple roles for finer access control. Community Edition provides multiple users that can be assigned to limited set of roles. There are three fixed roles in the community edition of Couchbase providing coarser access control: Bucket Full Access (bucket_full_access[*]), Admin (admin), and Read Only Admin (ro_admin).

      Example Scenarios

      Couchbase RBAC provides a secure solution for each of the following scenarios:

      • An application consists of several services, each of which has a different purpose. Compliance demands that each service be given a different set of read and write privileges, in order to constrain its activities to those absolutely required.

      • An application is available to several different classes of user. Each user-class has a different set of requirements for reading and writing data. Compliance demands that each user-class be given no more than the minimum privileges for supporting its requirements.

      • A Couchbase bucket has been defined to contain sensitive data that should be accessible to only a minimal subset of administrators. While highly select members of the subset should be granted either read or read-write privileges on the data itself (for example, in order to define Views, set up XDCR filters, or run queries); others should be granted access only to statistical data provided in support of the bucket (for example, in relation to memory-management or performance).

      • Test and production environments respectively require different degrees of constraint to be applied to read and write access. Administrators, developers, applications, and services should therefore each be granted one set of privileges for the test environment, and another (more restrictive) for the production.

      RBAC Concepts

      The following concepts are essential to an understanding of Couchbase RBAC:

      • Resource: An entity the access to which must be controlled. A resource can be specified either individually, by name; or as a group (for example, all buckets), by means of a wildcard character. The complete list of resources to which RBAC is applied is provided in Roles.

      • Privilege: The right, assigned by Couchbase Server, to apply an action to a resource. Possible actions include read, write, and execute. The associations of privileges to resources and roles are explained in Roles.

      • Role: An entity associated with a fixed set of privileges. The association of privileges to roles is described in Roles.

      • User: An identity, recognized by Couchbase Server, based on the passing of a username and password. A user can be assigned one or more roles: the privileges associated with each assigned role determine the resource-access granted the user. Users can be local (defined on Couchbase Server) or external (defined on a remote, network-accessible system). Each user might be an administrator or an application. For information on how to manage users, see Manage Users and Roles.

      RBAC Security Model

      Couchbase RBAC controls access to cluster-resources. Resources can only be accessed by users. A user may be an administrator or an application.

      Users can be added to Couchbase Server by the Full Administrator. Each user must be defined with a username and password. When attempting to access resources, each user must authenticate by means of these credentials.

      A user can be assigned one or more roles by the Full Administrator. Each role is itself associated with a subset of privileges; a privilege being a form of action, such as Read, Write, Execute, or Manage. Each privilege is associated with a resource; such as a bucket, index, view, or DCP stream.

      For example, the Data Reader role features the Read privilege, which is applied to the data of a bucket. When a user has been assigned the Data Reader role, and attempts to gain read-access to the bucket’s data by submitting their credentials, Couchbase Server identifies the user, recognises their assigned role and privilege, and duly authorises read-access.

      Note that resource-access can optionally be specified by means of parameterisation. This means that a wildcard character has been used, during role-assignment, to specify that a privilege applies to all resource-instances within a resource-class: for example, to all buckets.

      Defining Users and Groups

      Couchbase Server allows users to be defined individually, on the cluster. Each user so defined is of one of the following kinds:

      • A local user. The username and password are defined and maintained on Couchbase Server.

      • An external user. The username is recorded on Couchbase Server. However, the username and password are defined and maintained outside the cluster: for example, on a remote LDAP server.

      Couchbase-Server roles can be assigned both to local and to external users. Roles can be assigned in either or both of the following ways:

      • Directly. The user is associated directly with one or more Couchbase-Server roles.

      • By Group. A Couchbase-Server user-group is defined, and roles are assigned to the user-group. The user is made a member of the user-group, and thereby inherits all the roles of the group. A user can be a member of any number of groups.

      Note that by means of LDAP Group Support, the roles assigned to a Couchbase-Server user-group can be inherited by users not defined on Couchbase Server. For a detailed account, see Authentication Domains.

      See Manage Users, Groups, and Roles, for details on creating users and assigning roles.