This is the seventeenth and final article in our series on running the ClickHouse® database on Kubernetes with the Altinity® Kubernetes Operator. It covers a specialized topic for regulated environments: deploying ClickHouse in a FIPS 140-3 compliant posture. If you do not work under such requirements you can treat this as optional, but if you do, the operator makes compliance far more achievable.
What FIPS 140-3 is and who needs it
FIPS 140-3 is a United States government standard that specifies security requirements for cryptographic modules, the components that perform encryption. Organizations that work with US federal agencies, and many in regulated industries such as healthcare and finance, are required to use validated cryptographic modules and to run their systems in a FIPS-approved configuration. In practice this means using FIPS-built software and ensuring all traffic is encrypted with approved algorithms.
FIPS support in the Altinity Kubernetes Operator arrived in version 0.27.1, released on 4 June 2026. You need that version or later, and you must run the FIPS build of the operator itself, since the compliance starts with the operator's own cryptographic module.
The three hardening controls
The operator expresses its FIPS posture through three independent controls, set in a ClickHouseOperatorConfiguration resource. They are orthogonal: you can enable any one, any two, or all three.
The first is transport hardening, security.policy: Enforced. This coerces every connection the operator makes to use strict, verified TLS, secures its internal communication, and rejects plaintext coordination traffic. It hardens transport without asserting anything about the binary.
The second is the cryptographic-module gate, security.fips.enforced: "true". This makes the operator assert at startup that its binary was built with the validated Go FIPS 140-3 cryptographic module, and refuse to run if it was not. It also implies verified TLS, since a FIPS-asserting operator always wants encrypted, verified connections.
The third is the workload supply-chain gate, security.images.policy: FIPSRequired. This requires that every ClickHouse and Keeper image the operator deploys is a FIPS build. It checks the image tag and confirms the running server reports a FIPS version, and it rejects anything that does not comply.
Here is a configuration that turns on all three:
apiVersion: "clickhouse.altinity.com/v1"
kind: "ClickHouseOperatorConfiguration"
metadata:
name: chop-fips
namespace: kube-system
spec:
security:
policy: Enforced
fips:
enforced: "true"
images:
policy: FIPSRequiredWith this applied and a FIPS-built operator running, your control plane is in a FIPS posture and will only deploy FIPS-compliant databases.
FIPS-built images
Compliance requires FIPS builds of ClickHouse and Keeper, not the standard images. Altinity publishes these with a distinguishing tag suffix, for example altinity/clickhouse-server:<version>.altinityfips and altinity/clickhouse-keeper:<version>.altinityfips. Replace <version> with the current Altinity FIPS build. The image policy above specifically looks for fips in the tag and in the server's reported version, so using these builds is what satisfies the workload gate.
A FIPS ClickHouse cluster
A compliant cluster runs on FIPS images, exposes only TLS ports, and validates certificates against a trusted certificate authority stored in a Secret. The plaintext ports are removed and replaced with their secure equivalents. Here is the shape of such a CHI:
apiVersion: "clickhouse.altinity.com/v1"
kind: "ClickHouseInstallation"
metadata:
name: "ch-fips"
spec:
defaults:
templates:
podTemplate: fips
security:
clickhouse:
tls:
rootCASecretRef:
name: clickhouse-certs
key: ca.crt
configuration:
clusters:
- name: "default"
secure: "yes"
insecure: "no"
layout:
shardsCount: 1
replicasCount: 2
settings:
http_port: _removed_
tcp_port: _removed_
interserver_http_port: _removed_
https_port: 8443
tcp_port_secure: 9440
interserver_https_port: 9010
templates:
podTemplates:
- name: fips
spec:
containers:
- name: clickhouse
image: altinity/clickhouse-server:<version>.altinityfipsThe cluster sets secure: "yes" with insecure: "no" to use secure interfaces, removes the plaintext ports through settings, and trusts the shared certificate authority through rootCASecretRef. You supply the server certificate, key, and an OpenSSL configuration that pins FIPS-approved cipher suites, all mounted from the clickhouse-certs Secret, following the certificate pattern from the security article. The Keeper ensemble runs the matching FIPS Keeper image with the same TLS-only setup, exposing the secure Keeper port rather than the plaintext one.
Knowing the compliance boundary
Honesty about scope matters for compliance. The operator's FIPS boundary covers the operator and metrics-exporter binaries and the encrypted connections between components. A few paths sit outside it by design: the Prometheus metrics endpoints remain plain HTTP, since metrics are not sensitive cryptographic material, and the TLS is server-authentication only rather than mutual TLS. Understand these boundaries when you document your compliance posture, and place the plain-text metrics endpoints on a trusted internal network.
Recovering from a policy violation
If the image policy is on and you deploy a cluster with a non-FIPS image, the operator does not silently run it. The cluster lands in an Aborted status with a reason indicating a FIPS image policy violation. The fix is straightforward: edit the CHI or CHK to reference a properly FIPS-tagged image and reapply. The operator re-evaluates and proceeds once the image complies. This fail-closed behaviour is exactly what you want in a regulated environment, since it prevents a non-compliant database from ever serving traffic.
Series conclusion
That completes the series. You started with no Kubernetes knowledge and have arrived at a FIPS-compliant, replicated, monitored, production-grade ClickHouse deployment. Along the way you learned Kubernetes fundamentals, built a local cluster, deployed ClickHouse by hand and then with the operator, added storage, configuration, Keeper, and replication, scaled with shards and placement, handled upgrades, monitoring, security, resources, a production capstone, tiered storage, and troubleshooting. You now have the foundation to run ClickHouse on Kubernetes with confidence.
