CockroachDB Dedicated has 2 Levels of Authentication

• CockroachDB Cloud Console
• SQL Users

In this Blog, we will discuss how both of these should be used to secure your Cockroach Cloud Organization account.

Website Link for further Details - https://www.cockroachlabs.com/docs/cockroachcloud/console-access-management.html

CockroachDB Cloud Console

Within the CockroachDB Cloud console, you can add organization users, where the human users can authenticate using SAML/OIDC-based SSO. When adding users to the CockroachDB Cloud console, it will grant them privileges to interact with the CockroachDB Cloud UI or CLI.

The 2 organization roles that are currently available are:

• Administrators - They get full access to the cloud organization allowing them to complete tasks such as Creating Clusters, Scaling Clusters, Adding SQL Users, Adding Org Users etc.
• Developers - They can only get a read-only view of the organization. They are not permitted to add organization or SQL users, create & manage clusters etc.

It is important to note that developers do not have to be added as an organization user to interact with a database cluster. It is more common and best practice to create SQL users for the developers and applications which will give them access to the clusters themselves and not to the Cloud Console.

Recommendation for the Cloud Console Security

The first user who creates the CockroachDB Cloud organization will automatically be given admin privileges. This user should be used to create all other logins as needed and could be treated as a super-admin.

If using Terraform and/or a combination of API to manage the deployment of CockroachDB clusters in CockroachDB Cloud, then a service account with admin privileges should be created as an automation user. This should be the only account that manages the infrastructure such as creating and modifying clusters.

A limited number of other users could be optionally created with the admin role to help balance and share the responsibilities to manage organization and SQL users from the CockroachDB Cloud Console. If read Access is required to the DB console for monitoring of the individual clusters, then some users could be optionally assigned only the Developer Role in the cloud organization.

SQL Users

A full RBAC model is in place for users interacting with individual clusters in CockroachDB Cloud.

SQL Users can be created in the following ways:

• CockroachDB Cloud Console
• CockroachDB Cloud CLI

If creating a SQL user through the CockroachDB Cloud Console, it will be given admin privileges over the cluster by default i.e. they would have read and write permissions to all databases & tables in the cluster. This goes against the least privilege principle so we recommend doing this only within dev or test environments. For production databases, we recommend using the CLI mechanism.

When creating Users through the CLI you can set the required privileges at the time of onboarding, and could add/remove them as per the evolving access control needs for different types of users to different databases & tables. This is the secure and recommended way of adding application and human users to your clusters. The only caveat to this is any user created in this way will not show up in the SQL USERS tab of the CockroachDB Cloud console.

In both cases, SQL users are scoped to the individual cluster and NOT to the entire cloud organization. Meaning a user created in a Test cluster will not have access to a prod cluster unless explicitly added to that cluster.

More information on Roles and Grants . We recommend creating different read/writer/operator roles for different data domains and then assigning those to relevant SQL users.

Recommendation for SQL Users

We recommend creating SQL users through the CLI with the required privileges in a cluster and changing those as needed over time. In order to do this, you will need to log in to the cluster with a SQL Admin user.

Every cluster should get at least one SQL admin user. These are typically DBAs who are administering the cluster. Such admin users should create the required roles and users on a data domain or application-by-application or user-by-user basis.