Configure encryption and authentication to secure Calico components

Connections from Calico components to etcd

  • Operator
  • Manifest

Operator based installations do not required communication to etcd, and so this section does not apply.

If you are using the etcd datastore, we recommend enabling mutual TLS authentication on its connections as follows.

Connections from Calico components to kube-apiserver (Kubernetes and OpenShift)

We recommend enabling TLS on kube-apiserver, as well as the client certificate and JSON web token (JWT) authentication modules. This ensures that all of its communications with Calico components occur over TLS. The Calico components present either an X.509 certificate or a JWT to kube-apiserver so that kube-apiserver can verify their identities.

Connections from Felix to Typha (Kubernetes)

  • Operator
  • Manifest

Operator based installations automatically configure mutual TLS authentication on connections from Felix to Typha.

We recommend enabling mutual TLS authentication on connections from Felix to Typha. To do so, you must provision Typha with a server certificate and Felix with a client certificate. Each service will need the private key associated with their certificate. In addition, you must configure one of the following.

  • SPIFFE identifiers (recommended): Generate a SPIFFE identifier for Felix, set ClientURISAN on Typha to Felix’s SPIFFE ID, and include Felix’s SPIFFE ID in the URI SAN field of its certificate. Similarly, generate a SPIFFE identifier for Typha, set TyphaURISAN on Felix to Typha’s SPIFFE ID, and include Typha’s SPIFFE ID in the URI SAN field of its certificate.

  • Common Name identifiers: Configure ClientCN on Typha to the value in the Common Name of Felix’s certificate. Configure ClientCN on Felix to the value in the Common Name of Typha’s certificate.

Configure encryption and authentication to secure Calico components - 图1tip

If you are migrating from Common Name to SPIFFE identifiers, you can set both values. If either matches, the communication succeeds.

Here is an example of how you can secure the Felix-Typha communications in your cluster:

  1. Choose a certificate authority, or set up your own.

  2. Obtain or generate the following leaf certificates, signed by that authority, and corresponding keys:

    • A certificate for each Felix with Common Name typha-client and extended key usage ClientAuth.

    • A certificate for each Typha with Common Name typha-server and extended key usage ServerAuth.

  3. Configure each Typha with:

    • CAFile pointing to the certificate authority certificate

    • ServerCertFile pointing to that Typha’s certificate

    • ServerKeyFile pointing to that Typha’s key

    • ClientCN set to typha-client

    • ClientURISAN unset.

  4. Configure each Felix with:

    • TyphaCAFile pointing to the Certificate Authority certificate

    • TyphaCertFile pointing to that Felix’s certificate

    • TyphaKeyFile pointing to that Felix’s key

    • TyphaCN set to typha-server

    • TyphaURISAN unset.

For a SPIFFE-compliant deployment you can follow the same procedure as above, except:

  1. Choose SPIFFE Identities to represent Felix and Typha.

  2. When generating leaf certificates for Felix and Typha, put the relevant SPIFFE Identity in the certificate as a URI SAN.

  3. Leave ClientCN and TyphaCN unset.

  4. Set Typha’s ClientURISAN parameter to the SPIFFE Identity for Felix that you use in each Felix certificate.

  5. Set Felix’s TyphaURISAN parameter to the SPIFFE Identity for Typha.

For detailed reference information on these parameters, refer to: