Audits the security posture of a CockroachDB cluster (Cloud or self-hosted) across network, authentication, authorization, encryption, audit logging, and backup dimensions. Use when assessing cluster security readiness, preparing for compliance reviews, or investigating security configuration gaps.
Audits the security posture of a CockroachDB cluster (Cloud or self-hosted) across network, authentication, authorization, encryption, audit logging, and backup dimensions. Use when assessing cluster security readiness, preparing for compliance reviews, or investigating security configuration gaps.
compatibility
Requires ccloud CLI authenticated via `ccloud auth login` and SQL access via cockroach sql with admin or VIEWACTIVITY privilege.
metadata
{"author":"cockroachdb","version":"1.0"}
Auditing Cloud Cluster Security
Assesses the security posture of a CockroachDB Cloud cluster by examining network access controls, authentication and SSO configuration, user authorization, encryption, audit logging, and backup status. Produces a structured PASS/WARN/FAIL report with remediation links for each finding. Supports both CockroachDB Cloud and self-hosted clusters — checks that don't apply to the deployment model are marked N/A.
Read-only audit: All operations are read-only. No cluster state is modified during the assessment.
When to Use This Skill
Preparing for SOC 2, HIPAA, or other compliance reviews
Conducting periodic security posture assessments
Onboarding a new production cluster and validating security baseline
Investigating security configuration gaps after an incident
Reviewing cluster security before a major release or customer onboarding
Deployment model, environment, compliance, data sensitivity
Cluster Configuration
ccloud
Version, plan, regions
Assessment Workflow
Step 0: Verify Prerequisites
Run the following checks to determine which tools are available. The audit proceeds regardless — missing tools degrade specific checks rather than blocking the audit.
# Verify SQL connectivity
cockroach sql --url "<connection-string>" -e "SELECT current_user();"# Check openssl version (v3+ recommended for PQC probes)
openssl version
# Check sslyze availabilitywhich sslyze && sslyze --version
Report tool availability before proceeding:
Tool
Status
Impact if Missing
ccloud
Available / Missing
Network, CMEK, and managed backup checks skipped (Cloud only)
cockroach sql
Available / Missing
All SQL-based checks skipped — audit severely limited
openssl (v3+)
Available / Missing
TLS cipher and PQC probing degraded
sslyze
Available / Missing
Comprehensive TLS enumeration unavailable; falls back to openssl
If cockroach sql is unavailable, warn the user that the audit will be limited to ccloud-only checks and recommend resolving connectivity before continuing. For missing optional tools (openssl, sslyze), note which checks will produce incomplete results and proceed.
Step 1: Gather Cluster Metadata and Confirm Audit Context
Cloud clusters:
# List clusters and identify target
ccloud cluster list -o json
# Get cluster details (use cluster name or ID)
ccloud cluster info <cluster-name> -o json
Self-hosted clusters:
# Gather metadata via SQL and cockroach CLI
cockroach node status --certs-dir=<certs-dir> --host=<host>
cockroach sql --url "<connection-string>" -e "SELECT version();"
Record: cluster ID, plan type (Basic/Standard/Advanced or self-hosted), cloud provider, regions, CockroachDB version. See ccloud commands reference for Cloud CLI syntax.
Confirm audit context: Present auto-detected metadata (cluster name, version, provider, regions, plan) and ask the user to confirm and provide:
Deployment model: CockroachDB Cloud / self-hosted
Environment: production / staging / development / sandbox
Compliance frameworks: SOC 2, HIPAA, PCI DSS, ISO 27001, GDPR, or none
Data sensitivity: PII/PHI, financial/payment, internal business, public/non-sensitive
Defaults (if user confirms without changes): Cloud, production, no compliance, internal business data. Deployment model determines check applicability (below). Environment and compliance calibrate severity (see Severity Adjustments).
Check Applicability by Deployment Model
Check
Cloud
Self-Hosted
IP allowlists (ccloud)
Yes (all tiers)
N/A — managed externally via firewall/VPC
Ingress Private Endpoints (ccloud)
Yes (Standard+, Advanced)
N/A
Egress Private Endpoints (ccloud)
Yes (Advanced)
N/A
HBA configuration (SQL)
Yes
Yes — primary network-level auth control
Cloud Console SSO
Yes
N/A
SCIM 2.0
Yes
N/A
Database SSO (OIDC)
Yes
Yes
Database SSO (LDAP/AD)
Yes
Yes
Users & Roles (SQL)
Yes
Yes
Privileges (SQL)
Yes
Yes
CMEK (ccloud)
Yes
N/A — check Enterprise Encryption instead
Enterprise Encryption
N/A
Yes — verify encryption-at-rest via store config
TLS
Always PASS (enforced)
Check — verify certs, expiry, config
TLS 1.3 / PQC / Key Size
Yes (INFO)
Yes (INFO)
Audit Logging (SQL)
Yes
Yes
Managed Backups (ccloud)
Yes (automatic)
N/A
Self-Managed Backups (SQL)
Optional (if managed backups present)
Yes — verify backup schedules exist and are running
Skip N/A checks for the detected deployment model and mark them as [N/A] in the report rather than PASS/FAIL.
Step 2: Assess Network Security
Cloud clusters: Check all three layers based on cluster tier:
# IP allowlists (all tiers)
ccloud cluster networking allowlist list <cluster-id> -o json
# Ingress private endpoints (Standard+, Advanced) — via Cloud Console or API# Cloud Console: Networking > Private endpoint tab# API: GET /api/v1/clusters/{cluster_id}/networking/private-endpoint-connections# Egress private endpoints (Advanced only) — via Cloud Console or API# Cloud Console: Networking > Egress tab# API: GET /api/v1/clusters/{cluster_id}/networking/egress-endpoints
FAIL if 0.0.0.0/0 is in the IP allowlist (open to all traffic)
WARN if allowlist contains broad CIDR ranges (e.g., /8 or /16)
WARN if no private endpoints configured on Advanced plan
INFO if private endpoints not available on current tier
PASS if allowlist contains only specific, narrow CIDR ranges or private endpoints are configured
Self-hosted clusters: Check HBA configuration as the primary network-level auth control:
SHOW CLUSTER SETTING server.host_based_authentication.configuration;
Evaluate (self-hosted):
WARN if HBA configuration is empty or default — network security may be managed externally (firewalls, security groups, VPCs), so this is WARN not FAIL
PASS if HBA rules restrict connections by IP, subnet, or auth method
Step 3: Check SSO and SCIM Configuration
For self-hosted clusters, skip Cloud Console SSO and SCIM checks (N/A). Database SSO checks still apply — check OIDC and/or LDAP/AD configuration.
Cloud Console SSO (Cloud Console UI > Organization Settings > Authentication — not via ccloud CLI):
FAIL if SSO is not configured
PASS if SAML or OIDC SSO is enabled and enforced
Database SSO (Cluster SSO) — OIDC:
-- Check if Cluster SSO is enabled for SQL authenticationSHOW CLUSTER SETTING server.oidc_authentication.enabled;
SHOW CLUSTER SETTING server.oidc_authentication.provider_url;
FAIL if server.oidc_authentication.enabled is false
PASS if enabled with a valid provider URL
Database SSO — LDAP/AD (Cloud and self-hosted):
-- Check if LDAP authentication is configured via HBASHOW CLUSTER SETTING server.host_based_authentication.configuration;
-- Look for ldap auth method entries in the HBA configuration
PASS if HBA contains entries with ldap auth method
INFO if LDAP is not configured (OIDC may be used instead)
-- Count admin role membersSELECTCOUNT(*) AS admin_count
FROM [SHOW GRANTS ON ROLE admin];
-- Check PUBLIC role privileges on the current database-- Note: SHOW GRANTS FOR public is scoped to the current database.-- Run this query from each application database to get full coverage.SELECT
database_name,
schema_name,
object_name,
object_type,
privilege_type
FROM [SHOW GRANTS FOR public]
WHERE privilege_type NOTIN ('USAGE')
AND schema_name ='public'ORDERBY database_name, object_name;
Important:SHOW GRANTS FOR public is scoped to the current database. Run SHOW DATABASES; and repeat the query from each database for full coverage.
Evaluate:
FAIL if more than 5 users have admin role
FAIL if PUBLIC has SELECT, INSERT, UPDATE, or DELETE on application tables
WARN if admin count is between 3 and 5
PASS if admin count is 1-2 and PUBLIC has minimal grants
Step 6: Verify Encryption
CMEK status (Cloud clusters):
# Check CMEK configuration (Advanced plan with Advanced Security Add-on)
ccloud cluster info <cluster-name> -o json
# Look for cmek_config in the output
Evaluate by plan type (Cloud):
Standard plan: INFO — "Upgrade to Advanced plan with Advanced Security Add-on to enable CMEK"
Advanced plan without Advanced Security Add-on: INFO — "Add Advanced Security Add-on to enable CMEK"
Advanced plan with Advanced Security Add-on, CMEK not enabled: FAIL — CMEK not enabled despite plan supporting it
Advanced plan with Advanced Security Add-on, CMEK enabled: PASS
Enterprise Encryption (self-hosted — skip CMEK, check this instead):
Enterprise Encryption-at-Rest is configured at node start via the
--enterprise-encryption flag and is not exposed as a SQL cluster setting.
Confirm it by:
Inspecting the node's startup arguments (process command line / systemd unit
/ Kubernetes pod spec) for --enterprise-encryption=...
INFO — TLS version (should be TLS 1.3; note if TLS 1.2 only)
INFO — PQC hybrid cipher support (e.g., X25519MLKEM768) — emerging, not yet a FAIL condition
INFO — Encryption key size (check for AES-256; note if AES-128)
Note: CockroachDB uses PostgreSQL wire protocol, so openssl s_client requires -starttls postgres to negotiate TLS correctly. Without this flag, the connection will fail. sslyze similarly requires --starttls postgres.
