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.

Upgrading to RBAC

    +
    Couchbase provides an upgrade path, whereby users can seamlessly transition their activities from Couchbase Server 4.6 and earlier (which are all pre-RBAC releases) to 5.0 and post-5.0 (which are RBAC-enabled releases).

    Migration to 5.0 and post-5.0

    Releases of Couchbase Server prior to 5.0 did not feature the Role-Based Access Control that is now provided. 5.0/post-5.0 administrators and developers must therefore become familiar with the new model, and modify procedures as appropriate.

    However, to ensure the continued running of legacy applications, Couchbase Server provides an automated migration of existing buckets to the new RBAC model, as part of the upgrade procedure. The following sections explain this migration.

    Legacy Bucket-Definitions

    In releases of Couchbase Server prior to 5.0, buckets could either be established on the standard port (11211), which was SASL-enabled, and required that the bucket be password-protected; or on an administrator-dedicated port, in which case the bucket was accessible by means of the ASCII protocol, and was not password-protected.

    Each of these types of bucket-definition is considered below, in relation to how the corresponding buckets are accessed following upgrade to Couchbase Server 5.0 and beyond.

    Legacy Buckets on the Standard Port

    Legacy buckets that were defined on the SASL-enabled standard port were protected by a bucket-password. These bucket-passwords are no longer supported, in Couchbase Server 5.0 and beyond. Instead, buckets, as other resources, must be accessed through RBAC.

    During the upgrade process, Couchbase performs forward-migration on legacy, password-protected buckets; so that following upgrade, the buckets can be accessed through RBAC, without immediate changes to authentication-procedures required. This forward-migration has the following characteristics:

    • Any existing bucket that is resident on the standard port is stripped of its legacy bucket-password.

    • After all cluster-nodes have successfully been upgraded, for each bucket that has been stripped of its bucket-password, a new user is created; whose username is identical to the name of the bucket. This user appears along with all others, in the Security screen of the Couchbase Web Console.

    • Each new user that has been defined to correspond to a legacy bucket that featured a bucket-password is assigned a user-password: this user-password is identical to the stripped, bucket-password of the legacy bucket; and will be referenced in association with the new user, in the Security screen of the Couchbase Web Console.

      Each new user that has been defined to correspond to a legacy bucket that featured no bucket-password is not assigned a user-password.

    • Each new user that has been defined in this way — either with or without a password — is assigned the Application Access role, by default. This role (which in RBAC-enabled versions of Couchbase Server prior to 5.5 was referred to as Full Bucket Access) allows the new user the same bucket-access privileges (including read-write on bucket-data) as were previously possible by means of the bucket-password; and is visible in association with the user in the Security screen of the Couchbase Web Console.

    • Applications that continue to attempt bucket-access by specifying the legacy bucket-name and (where appropriate) bucket-password do not fail; since the bucket-name is interpreted as a username, and the bucket-password as a corresponding user-password; and the bucket access-privilege thereby attained is identical to that attained under previous releases of Couchbase Server.