Skip to main content
This feature is in and subject to change. To share feedback and/or issues, contact Support. In a Bring Your Own Cloud (BYOC) deployment, you own the cloud account and Cockroach Labs operates the CockroachDB cluster inside it. This page describes the access Cockroach Labs has, how that access is constrained and audited, how you revoke it, and the compliance posture of the service. For information about the BYOC deployment model and the overall shared responsibility model, refer to the .

​
What Cockroach Labs can do in your account

During setup you grant Cockroach Labs a scoped cross-account identity: an IAM role on Amazon Web Services (AWS), a service principal on Microsoft Azure, or a service account on Google Cloud Platform (GCP). The permissions attached to that identity are published in full in the deployment guide for each cloud. They are limited to the resources that make up the CockroachDB deployment:
  • The managed Kubernetes cluster.
  • Compute instances.
  • Block storage.
  • Load balancers and private endpoints.
  • The backup bucket.
  • Key management for cluster and backup encryption.
  • Networking configuration.
  • System databases for CockroachDB.
  • The service quotas the cluster depends on.
Cockroach Labs does not have access to your broader corporate network, to other accounts or subscriptions in your organization, or to resources in the account that are unrelated to the deployment. For strong isolation, Cockroach Labs recommends creating a new AWS account, Azure subscription, or GCP project for CockroachDB BYOC, so that its cluster resources are isolated from your applications and other organizational infrastructure. Automated control plane operations do not take any destructive actions, such as cluster deletion.

​
Why the permissions cannot be reduced

The published permission set is the minimum required for the control plane to provision, operate, patch, back up, and heal a CockroachDB cluster over its full lifecycle. The list is not a setup-time permission set. It is required for Cockroach Labs to meet cluster uptime SLAs.
Do not remove, narrow, or condition the permissions after setup. Many of the permissions are exercised only during a specific lifecycle event, such as replacing a failed node, applying a patch, rotating an encryption key, or running a managed backup. Removing a permission might not cause an immediate error. A later operation that requires it can fail, often weeks later and during an incident. Reducing the permission set voids the availability commitment for the cluster.On AWS accounts, do not use resources that can affect the control plane’s ability to operate on CockroachDB clusters.
The following are not supported:
  • Reducing the permission set, including scoping a production deployment more tightly than a non-production one. If you want production and non-production deployments to have separate identities and separate blast radius, deploy them into separate cloud accounts. Each cloud account has its own cross-account identity and its own permission set.
  • Applying conditional or time-bounded policies, including policies that deny actions outside a maintenance window. The control plane must be able to act on a cluster health signal at any time. A restriction window that coincides with a node failure can leave the cluster degraded.
  • Applying service control policies or organization policies that restrict the required permission set. Guardrails that constrain the account to particular regions or services, without touching the permissions the deployment requires, are compatible.
  • Imposing a change freeze on the cross-account identity.

​
Human access

Cockroach Labs engineers have no standing access to customer cloud accounts. To act in a customer account, an engineer must request eligibility through a privileged access management workflow with a recorded justification. Access is granted just in time, is scoped to a specific account, and expires. All access is authenticated through the Cockroach Labs enterprise identity provider with multi-factor authentication, and can only be run on a corporate device in compliance with Cockroach Labs’ device policy. Because no engineer holds a persistent entitlement, offboarding does not depend on a separate revocation step. When a Cockroach Labs employee leaves, their identity provider account is deactivated through an HR-driven workflow within one business day of termination, and there is no standing grant to remove. Eligibility to request escalated access is itself restricted to a defined engineering group, and being in that group does not grant access. It grants only the ability to request it.

​
Audit Cockroach Labs access

Every action Cockroach Labs takes in your account is an authenticated cloud provider API call, so it is recorded in your own cloud provider audit log. You do not need to request logs from Cockroach Labs to review the actions Cockroach Labs has taken. On AWS, every role assumption is recorded in AWS CloudTrail with a grant-specific role session name, a source identity, and session tags that encode the requesting engineer’s identity and justification. To review all Cockroach Labs activity, filter CloudTrail on the ARN of the role you created:
You can alert on this activity in real time by using Amazon EventBridge rules or Amazon CloudWatch alarms. On Azure, activity performed by the service principal is recorded in the Azure Activity Log for the subscription. On GCP, it is recorded in Cloud Audit Logs for the project.
Session identifiers in your audit log encode the grant, not the individual’s name. If you require attribution of a specific session to a named Cockroach Labs individual, contact Cockroach Labs support with the session identifier.

​
Revoke access

You can revoke Cockroach Labs access at any time and without notice by removing the trust relationship on the role, deleting the service principal, or attaching a deny-all policy. Revocation takes effect immediately. The following stops when access is revoked:
  • Provisioning, scaling, and configuration changes.
  • Patching and version upgrades.
  • Managed backup orchestration.
  • Automated healing, including replacement of a failed node.
  • Monitoring, alerting, and support’s ability to diagnose the cluster.
  • The availability commitment for the cluster.
The following continues:
  • SQL traffic. The cluster keeps serving your applications.
  • Raft replication and consensus.
Restoring access restores management. Revocation is a control you hold, not a support path. If you are considering revocation in response to a security concern, please contact Cockroach Labs support first.

​
Encryption

The following forms of encryption are used in a BYOC deployment:
  • In transit: Traffic between CockroachDB nodes uses TLS 1.3. Client and application connections use TLS 1.2 or TLS 1.3. Data sent from your account to Cockroach Labs is encrypted in transit.
  • At rest: Cluster storage is encrypted at the infrastructure level using your cloud provider’s disk encryption. This applies whether or not you configure anything further. You can additionally enable customer-managed encryption keys (CMEK), which are supported with AWS KMS, Google Cloud KMS, and Azure Key Vault. CMEK applies both to cluster-level encryption and to the encryption of managed backups. Key material remains in your own cloud account and under your control at all times. Refer to .
  • Backups: Managed backups are written to a storage bucket in your own cloud account and encrypted with a key you control.

​
Compliance

The following applies to the BYOC service specifically. Reports are available under a non-disclosure agreement (NDA) through your Cockroach Labs account team.

​
Data protection

Row-level data in a BYOC cluster remains in your own cloud account, in the region you select, and Cockroach Labs does not process it. Operational telemetry and redacted logs, which contain no personal data or payment data, are processed by Cockroach Labs in the United States. Because you control the data in your clusters, you remain responsible for its classification and retention, and for responding to data subject requests relating to it. For personal data Cockroach Labs processes as part of the commercial relationship, refer to the Cockroach Labs Data Processing Addendum.

​
Shared responsibility for security

The following table describes the split of security responsibilities between you and Cockroach Labs:

​
Availability commitment

The availability commitment for a BYOC deployment applies to the CockroachDB cluster. Cockroach Labs does not publish a separate uptime commitment for the control plane. The control plane has a recovery time objective of 4 hours, its status is published at status.cockroachlabs.cloud, and a control plane outage does not interrupt SQL traffic. The commitment does not apply if the cross-account identity or its permissions are removed or restricted, if required service quotas are exhausted, or if managed resources in the account are modified outside of Cockroach Labs.

​
Next steps