Skip to main content
Calico Enterprise 3.19 (latest) documentation

Provide TLS certificates for log storage

Big picture

Provide TLS certificates to secure access to Calico Enterprise to the log storage.

Value

Providing TLS certificates for Calico Enterprise components is recommended as part of a zero trust network model for security.

Before you begin...

By default, the Calico Enterprise log storage uses self-signed certificates on connections. To provide TLS certificates, get the certificate and key pair for the Calico Enterprise log storage using any X.509-compatible tool or from your organization's Certificate Authority. The certificate must include the following Subject Alternate Names or DNS names tigera-secure-es-http.tigera-elasticsearch.svc and tigera-secure-es-gateway-http.tigera-elasticsearch.svc.

If your cluster has Windows nodes, the certificate must additionally include tigera-secure-es-http.tigera-elasticsearch.svc.<cluster_domain> where <cluster_domain> is the local domain specified for in-cluster DNS.

How to

Add TLS certificates for log storage

To provide TLS certificates for use by Calico Enterprise components during deployment, you must create a secret before applying the 'custom-resource.yaml' or before creating the LogStorage resource. Use the following command to create a secret:

kubectl create secret generic tigera-secure-elasticsearch-cert -n tigera-operator --from-file=tls.crt=</path/to/certificate-file> --from-file=tls.key=</path/to/key-file>

To update existing certificates, run the following command:

kubectl create secret generic tigera-secure-elasticsearch-cert -n tigera-operator --from-file=tls.crt=</path/to/certificate-file> --from-file=tls.key=</path/to/key-file> --dry-run -o yaml --save-config | kubectl replace -f -
note

If the Calico Enterprise log storage already exists, you must manually delete the log storage pods one by one after updating the secret. These pods will be in the tigera-elasticsearch namespace with the prefix, tigera-secure-es. Other Calico Enterprise components will not be unable to communicate with log storage until the pods are restarted.