ClickHouse Cloud Enterprise: how do we enable SAML SSO + private networking + CMEK?

ClickHouse Cloud Enterprise adds the controls security‑sensitive teams expect—enterprise SSO, private networking, and customer-managed encryption keys—on top of the same millisecond-query, columnar engine you’d run yourself. The mechanics are straightforward: identity is delegated to your IdP via SAML, network paths are locked down with VPC/VNet peering or Private Service Connect equivalents, and data‑at‑rest encryption is anchored in your KMS keys.

Quick Answer: In ClickHouse Cloud Enterprise, SAML SSO, private networking, and CMEK are configured at the organization and project level through ClickHouse Cloud support and your account team. You integrate your IdP for SAML, connect your cloud network to ClickHouse’s private endpoints, and register your cloud KMS keys so that data-at-rest encryption uses your CMEK instead of provider‑managed keys.

Why This Matters

If you’re standardizing on ClickHouse as the “leading database for AI” in a regulated environment, identity, network, and key management can’t be afterthoughts. You need the same guarantees you’d build yourself—centralized access control via SAML SSO, no public data paths, and full control over encryption keys—without re‑implementing observability, autoscaling, and backup logic from scratch.

When those pieces are handled in ClickHouse Cloud Enterprise:

Key Benefits:

• Centralized identity & access control: SAML SSO plugs ClickHouse Cloud into your existing IdP and RBAC processes, reducing local user sprawl and making offboarding reliable.
• Hardened network perimeter: Private networking keeps SQL traffic on your cloud backbone, not the public internet, while still delivering millisecond queries at scale.
• Customer-managed encryption keys (CMEK): Your KMS keys control data-at-rest encryption, aligning ClickHouse with corporate key rotation, audit, and revocation policies.

Core Concepts & Key Points

Concept	Definition	Why it's important
SAML SSO	A standards-based single sign-on integration where ClickHouse Cloud trusts assertions from your enterprise identity provider (Okta, Azure AD, Google Workspace, etc.).	Centralizes authentication, supports MFA and conditional access, and lets you manage ClickHouse access with existing groups and lifecycle automation.
Private Networking	Direct, non‑public connectivity between your VPC/VNet and ClickHouse Cloud (e.g., VPC peering, Private Service Connect / PrivateLink‑style endpoints).	Keeps data paths off the public internet, simplifies firewall rules, and often reduces egress and compliance risk.
CMEK	Customer-managed encryption keys stored in your cloud KMS (AWS KMS, GCP KMS, Azure Key Vault) used to encrypt ClickHouse Cloud data‑at‑rest.	Lets you own key lifecycle (creation, rotation, revocation) while ClickHouse handles storage and compute, satisfying stricter security and regulatory requirements.

How It Works (Step-by-Step)

At a high level, you’ll work with ClickHouse to enable Enterprise features for your organization, then plug in your own identity, network, and key management. The operational work is split between your cloud/identity teams and ClickHouse Cloud.

1. Enable SAML SSO

The goal here is to make ClickHouse Cloud a SAML service provider (SP) that trusts your IdP.

1. Gather IdP metadata

   • Decide which IdP will own ClickHouse access: Okta, Azure AD, Google Workspace, or another SAML‑compatible provider.
   • Create a new SAML application in your IdP and note:
     • Entity ID / Audience URI
     • Assertion Consumer Service (ACS) URL
     • NameID format (typically email)
     • Signing certificate (X.509)
   • Configure attributes you’ll send, at minimum:
     • email
     • first_name / last_name (or a combined name)
     • Optional: groups or roles for mapping into ClickHouse roles.

2. Coordinate with ClickHouse support / account team

   • Open a ticket or work with your account team indicating you want SAML SSO enabled for your ClickHouse Cloud organization.
   • Provide:
     • Your IdP metadata XML (or the Entity ID + SSO URL + certificate)
     • Attribute mapping (which SAML attributes represent email, name, and group/role claims)
     • Any constraints (e.g., only users in a specific IdP group can log in).

3. Configure role mapping

   • Decide which ClickHouse roles correspond to IdP groups, for example:
     • clickhouse-admins → full admin rights on the organization
     • clickhouse-analysts → query access to specific projects
     • clickhouse-readonly → read‑only SQL access
   • In Enterprise, these mappings are typically defined centrally so users are “just‑in‑time” provisioned and assigned roles based on IdP assertions.

4. Test and enforce SSO

   • Validate with a small group first:
     • Confirm sign‑in from the IdP UI and from the direct ClickHouse Cloud login.
     • Ensure users see the expected projects and cannot escalate privileges.
   • Once validated, request:
     • Enforcing SAML SSO as the only auth method for your org.
     • Optional Just‑In‑Time (JIT) user provisioning so you can avoid local account management.

From here on, your identity team governs ClickHouse Cloud access with its usual toolkit: MFA, conditional access, device posture checks, and group‑based access control.

2. Set Up Private Networking

Private networking ensures SQL traffic between your apps and ClickHouse Cloud never goes over the public internet.

The exact mechanism depends on your cloud provider and ClickHouse Cloud region, but the pattern is similar:

1. Choose a network model

   • VPC/VNet peering: Your VPC is peered with ClickHouse’s VPC in the same region/account boundary. Routing is configured so your subnets can reach ClickHouse service endpoints privately.
   • Private endpoint / PrivateLink‑style service: Your VPC hosts private interface endpoints that map to ClickHouse Cloud services, exposing them as private IPs in your subnets.
   • Transit gateway / hub‑and‑spoke: For larger estates, your existing network hub connects to ClickHouse so multiple VPCs can reach it without separate peerings.

2. Collect your network details

   • VPC/VNet ID and region
   • CIDR ranges of subnets that should have access
   • DNS domain preferences (e.g., whether you’ll use your own private DNS zone to resolve ClickHouse endpoints)
   • Any on‑prem connectivity details if you’re extending via VPN or Direct Connect/ExpressRoute.

3. Work with ClickHouse to establish connectivity

   • Provide the network information to ClickHouse support or your account team.
   • They’ll provision private endpoints or VPC peering on the ClickHouse side and share:
     • The private DNS names and IPs of your services
     • Any required security group / firewall rules
   • You update:
     • Route tables to send traffic to ClickHouse endpoints through the private link
     • Security groups / NACLs to allow traffic on ClickHouse ports from your application subnets.

4. Validate private connectivity

   • From an EC2/VM in your VPC, confirm that:

     • The ClickHouse hostname resolves to a private IP.

     • You can connect via TLS on the HTTPS or native port using your service credentials, e.g.:

       curl "https://<your-clickhouse-service>.<region>.clickhouse.cloud/?query=SELECT+1" \
         -u "default:<password>"
       

   • Use system.query_log inside ClickHouse to spot test queries and verify that client IPs match your private address space.

Once private networking is in place, you can further tighten security by:

• Restricting IP Access Lists in ClickHouse Cloud to your private address ranges.
• Disallowing public egress from app subnets wherever possible.

3. Configure CMEK (Customer-Managed Encryption Keys)

CMEK lets you anchor ClickHouse Cloud’s encryption‑at‑rest in your own KMS keys.

1. Prepare your KMS key

   • In your cloud provider’s KMS:
     • Create a symmetric encryption key dedicated to ClickHouse Cloud.
     • Enable key rotation according to your policy (often annually).
     • Tag it appropriately (e.g., App=ClickHouse, Environment=Prod).
   • Update the key policy to allow ClickHouse’s service principal to:
     • Encrypt / Decrypt
     • GenerateDataKey / GenerateDataKeyWithoutPlaintext
     • DescribeKey

2. Share key details with ClickHouse

   • Provide:
     • Key ARN / resource ID
     • Region
     • Any specific constraints (e.g., separate keys per environment or per project)
   • Work with ClickHouse support / your account team to attach CMEK to:
     • New services (recommended)
     • Existing services where CMEK migration is supported.

3. Understand encryption behavior

   • ClickHouse continues to encrypt data‑at‑rest (volumes, backups, logs) transparently, but:
     • The underlying data keys are wrapped with your KMS key.
     • Key usage is logged in your cloud provider’s audit logs.
   • You keep the ability to:
     • Rotate the KMS key (ClickHouse handles re‑encryption via normal KMS workflows).
     • Disable or revoke access if you need to lock down an environment.

4. Test and monitor

   • Run a few writes and reads in ClickHouse and confirm normal behavior and latency.
   • In your KMS audit logs, verify:
     • Key usage from the ClickHouse service principal.
     • No unexpected principals are using the key.

With CMEK in place, your infosec team can point to a clear boundary: ClickHouse operates the database, but your organization controls the cryptographic root of trust.

Common Mistakes to Avoid

• Treating SAML as “just a login screen change”: If you enable SAML SSO but don’t map IdP groups to ClickHouse roles, you’ll fall back to manual user management. Define clear group‑to‑role mappings and make your IdP the source of truth.
• Leaving public endpoints open after private networking: Once private networking is live, tighten IP Access Lists and firewall rules. Otherwise, you lose much of the benefit by keeping public paths available “just in case.”
• Using a shared KMS key for everything: A single “catch‑all” KMS key for dozens of systems makes audit and incident response painful. Use dedicated keys (at least per environment) and tag them clearly for ClickHouse.

Real-World Example

A fintech team running real-time fraud analytics on billions of events per day decided to move from a homegrown ClickHouse cluster to ClickHouse Cloud Enterprise. Security had three hard requirements before go‑live: SSO via their existing Okta setup, no public network exposure, and CMEK on all production data.

They worked with ClickHouse to:

• Configure SAML SSO with Okta, mapping existing groups (fraud-analytics-admins, fraud-analytics-readonly) directly into ClickHouse roles. Onboarding and offboarding became a matter of updating Okta, not touching the database.
• Establish private networking via VPC peering in their primary AWS region. Their fraud detection services now hit ClickHouse on private IPs with millisecond latency, and security groups only allow access from a dedicated application subnet.
• Attach CMEK keys in AWS KMS for prod and staging separately. Their infosec team can see every encryption and decryption call in CloudTrail and has the ability to revoke or rotate keys without waiting on a database migration.

The net effect: the data platform team stopped spending cycles patching nodes and babysitting merges; the security team got centralized identity, network isolation, and key control; and the fraud team kept their sub‑second investigative queries, now with managed autoscaling and backups.

Pro Tip: When you’re planning private networking and CMEK, treat ClickHouse Cloud like any other Tier‑0 service: involve your cloud networking and security engineering teams early, and agree upfront on VPC layout, DNS patterns, and KMS key ownership. It’s much easier to get this right before you create your first production service.

Summary

ClickHouse Cloud Enterprise gives you a managed, millisecond‑latency analytics engine with the controls enterprises expect: SAML SSO for centralized identity, private networking for a hardened perimeter, and CMEK so you retain cryptographic control of your data at rest. Each capability is configured once at the organization/project level and then recedes into the background, letting you focus on schemas, queries, and real workloads instead of IAM and TLS plumbing.

When implemented together, these features make ClickHouse Cloud a viable default for high‑sensitivity analytics, observability, and AI workloads that previously “had” to run on self‑managed clusters for security reasons.

Next Step

Get Started