Skip to main content

Prerequisites

  • The ClickHouse Private AWS Technical Setup Guide has been followed for setting up the AWS resources (do not do the Kubernetes Resources section) with the following considerations for FIPS:
    • The S3 bucket created here cannot contain any periods (.) when using FIPS as the S3 FIPS endpoints require virtual-host-style which will not work when the bucket name contains periods.
  • Use the following version tags:
    • clickhouse-server
      • <<SERVER_TAG>>-fips
    • clickhouse-keeper
      • <<KEEPER_TAG>>
    • clickhouse-operator
      • main-<<OPERATOR_TAG>>
    • helm/clickhouse-operator-helm
      • <<OPERATOR_TAG>>
    • helm/onprem-clickhouse-cluster
      • <<CR_HELM_TAG>>

Setup Tasks

  • Create certificates for the following:
    • Certificate authority (if applicable, for example if you are self-signing)
      • Name: ca.crt
    • Certificates:
      • Requirements for certificates:
        • They must be signed by the certificate authority created above or your existing certificate authority. If using an existing certificate authority, you must have access to the certificate so that it can be installed.
        • If FIPS compliance is required, they must be created using FIPS compliant algorithms and environments
        • You will need access to the public key (certificate) and the private key
        • The subject alternative names (SANs) must have the following entries:
          • *.c-${CLUSTER_NAME}-{server|keeper}-headless.ns-${CLUSTER_NAME}.svc.cluster.local - components in the cluster will use this DNS domain to communicate with each other. If your Kubernetes has a different domain name (.cluster.local), please replace it with your Kubernetes domain name
            • ${CLUSTER_NAME} is the name of the cluster you are creating
            • {server|keeper} indicates that either server or keeper should be used here depending on if the certificate is being installed in clickhouse-server or clickhouse-keeper, respectively
            • Example for cluster name default-xx-01:
              • Server: *.c-default-xx-01-server-headless.ns-default-xx-01.svc.cluster.local
              • Keeper: *.c-default-xx-01-keeper-headless.ns-default-xx-01.svc.cluster.local
      • Certificates to create:
        • One for connections to clickhouse-server
          • Private key name: server.key
          • Public key name: server.crt
        • One for connections from clickhouse-server (e.g. to clickhouse-keeper and other https sources like dictionaries)
          • Private key name: client.key
          • Public key name: client.crt
        • One for connections to clickhouse-keeper
          • Private key name: keeper.key
          • Public key name: keeper.crt
  • Install VolumeSnapshot CRDs
  • Install StorageClass via Helm Chart if you do not wish to use a custom or existing StorageClass
  • Install operator via Helm chart
  • Create Kubernetes secrets from generated certificates
  • Create the clickhousecluster custom resource

Technical Details

Creating Certificates With OpenSSL

The following shows how you can create self-signed certificates using OpenSSL. Please make sure that this method of creating and signing certificates is inline with your security policies before using in a production setting. Before proceeding you must choose a cluster name and it must be used later when creating your cluster. A unique set of certificates (excluding the CA certificate) must be created for each ClickHouse cluster being provisioned. This assumes you want a FIPS compliant certificate and that you have docker installed with access to the redhat docker image repository. If successful, this will generate a certificate authority that can be used for signing and certificate verification, and three sets of certificates (one for clickhouse-keeper, clickhouse-server, and clickhouse-server client usage). You will need to keep the *.crt (certificate/public key) files and the *.key (private key) files from each directory (ca/, server/, keeper/, and client/). If you have your own certificate authority that you will be signing with, you can exclude the CA certificate generation from the script and mount your own CA certificate into the docker image to use it for signing. Use a copy of this CA certificate in later steps of this setup guide when they refer to ca.crt (eg when creating the Kubernetes secrets). Note that the certificates generated below expire after 365 days. Please update this to fit your security requirements and please make a reminder to regenerate them before they expire.

Install Operator via Helm

Update version, ECR host, and availability zones (as determined by created VPC) as needed.

Create Kubernetes Certificate Secrets

Secrets must be installed in the same Kubernetes namespace where the ClickHouse cluster will run. If your cluster name is default-xx-01, then the namespace it will run in will be ns-default-xx-01. Ensure this namespace exists and update the CERT_DIR and CLUSTER_NAME variables below before executing the commands. The secrets must be named generated below with the key names as specified, do not change the secret names or key names.

Clickhousecluster CR

Be sure to use the correct FIPS version of the endpoints below for ECR and S3 which can be found here.

Install Validation

Port-forward the ClickHouse service to your local machine

To forward traffic from your local machine to the c-default-xx-01-server-any service, run:
This will forward port 9440 on the service to port 9440 on your local machine. You can now access the ClickHouse HTTP interface on https://localhost:9440.

Access ClickHouse and run query

Once the port is forwarded, you can connect to ClickHouse locally using a tool like clickhouse-client with the following configuration file. Be sure to update the path to your ca.crt file.
and run a simple query:
You should see output like this: