Set up Teleport Enterprise for secure database access to ClickHouse Private clusters in government/FIPS environments. This guide covers deploying Teleport on EKS, configuring database access, SAML authentication, and certificate rotation.
Prerequisites
- The FIPS/Government deployment has been completed with
SERVER_VERIFICATION_MODE=relaxed and KEEPER_VERIFICATION_MODE=relaxed (required for Teleport mTLS)
- Teleport Enterprise license
- The server certificate SAN must include
DNS.2 = c-${CLUSTER_NAME}-server-any.ns-${CLUSTER_NAME}.svc.${KUBERNETES_DOMAIN} (see Generate FIPS certificates)
Create a Node Group for Teleport
A dedicated node group for Teleport is optional. If you do not have Bottlerocket ARM FIPS nodes available, create a node group with the following configuration in the EKS console under Compute:
- Name: fips-arm64
- Node IAM role: create a new recommended role
- Kubernetes taints:
- Key:
group, Value: fips-arm64, Effect: NoSchedule
- AMI type: Bottlerocket ARM FIPS
- Instance types: m7g.large
- Scaling: Desired 2, Min 2, Max 3
Install Teleport Cluster on EKS
Create Namespace and License Secret
Generate FIPS Certificates for Teleport
Create the following script (generate_fips_certs_in_container_for_teleport.sh):
Run it (replace <CLUSTER_FQDN> with the FQDN of the Teleport service):
Create Certificate Secrets
Create Helm Values
Create eks_teleport_values.yaml. Replace the placeholders:
<CLUSTER_NAME>: The FQDN of the cluster
<VPN_SUBNETS>: VPN private subnets, comma-delimited (e.g., private-subnet-us-east-2a,private-subnet-us-east-2b,private-subnet-us-east-2c)
<BUCKET_NAME>: S3 bucket for Teleport session records
<NODE_SELECTOR>: Node selector value (e.g., fips-arm64)
This example deploys Teleport with FIPS on EKS. For other cloud providers, refer to the Teleport documentation.
Deploy Teleport Cluster
Get the Teleport Service External IP
Take the external IP and create a CNAME record in Route53 or your DNS provider. If the load balancer does not have a hostname:
Then create an A record instead.
Create a Teleport Provision Token
A provision token allows Teleport agents to join the cluster. Create teleport_provision_token_for_clickhouse.yaml:
Set Up the Teleport Agent
Create Agent Namespace
Create Agent Secrets
Create a secret for the Teleport proxy CA in the agent namespace:
Create a secret for the database CA (concatenate CAs if using multiple databases with different CAs). Create a file called db_cas.pem, then:
Create teleport_agent_values.yaml. Replace:
<CLICKHOUSE_CLUSTER_NAME>: Name of the provisioned cluster (e.g., default-aa-01)
<ENV>: Static label for this database (e.g., dev)
The YAML creates 2 database resources for 1 database because ClickHouse supports 2 protocols (HTTPS on 8443 and native TLS on 9440). Remove whichever you do not need.
Deploy the Agent
Add Teleport CA to ClickHouse Trusted List
Fetch the Teleport root CA and add it to the ClickHouse server certificate secret:
Restart the ClickHouse server pods to apply the new CA.
Create a Database Access Role
Create saml_clickhouse_user_role.yaml. Replace the user trait key with the attribute from your identity provider (e.g., http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress):
For more information on roles, see the Teleport documentation.
Create a SAML Connector
Create saml_connector.yaml. Replace <DOMAIN> with your Route53 domain and <Entity Descriptor> with the value from your identity provider:
For more information on SAML connectors, see the Teleport documentation.
Create Database Users
Exec into a ClickHouse server pod:
Connect to the database:
Create a user authenticated via SSL certificate CN (replace <DB_USER> with the username — typically the user’s email address from the identity provider):
Connect via Teleport
Add the Teleport CA to your system’s trusted CAs, or use the --insecure flag for development.
Replace:
<DOMAIN>: Your Route53 domain
<AUTH_TYPE>: Authentication type (e.g., samlconnector)
<TELEPORT_USER>: Teleport username
<DB_USER>: Database username
<CLICKHOUSE_CLUSTER_NAME>: ClickHouse cluster name (e.g., default-aa-01)
Day 2: Certificate Rotation
Teleport certificates expire and must be rotated before expiry.
Rotate Teleport Proxy Certificates
-
Generate new certificates using the script from Generate FIPS Certificates for Teleport. Ensure
CLUSTER_FQDN and other variables match your cluster.
The script must run on a FIPS-enabled host. Docker automatically mounts /proc, so as long as the container runs on a FIPS-enabled host, the generated certificates will be FIPS-compliant.
-
Append the new CA to the existing bundle in both namespaces:
-
Rolling restart Teleport:
-
Add the new Teleport CA to ClickHouse trusted list:
-
Replace the proxy certificate:
-
Remove the old CA from the bundle:
-
Clean up:
Reference
Last modified on August 7, 2026