Configure encryption and authentication to secure Calico components
Connections from Calico components to etcd
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.
Configure etcd to encrypt its communications with TLS and require clients to present certificates signed by the etcd certificate authority.
Configure each Calico component to verify the etcd server's identity and to present a certificate to the etcd server that is signed by the etcd certificate authority.
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 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
ClientURISANon Typha to Felix's SPIFFE ID, and include Felix's SPIFFE ID in the
URI SANfield of its certificate. Similarly, generate a SPIFFE identifier for Typha, set
TyphaURISANon Felix to Typha's SPIFFE ID, and include Typha's SPIFFE ID in the
URI SANfield of its certificate.
Common Name identifiers: Configure
ClientCNon Typha to the value in the
Common Nameof Felix's certificate. Configure
ClientCNon Felix to the value in the
Common Nameof Typha's certificate.
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:
Choose a certificate authority, or set up your own.
Obtain or generate the following leaf certificates, signed by that authority, and corresponding keys:
A certificate for each Felix with Common Name
typha-clientand extended key usage
A certificate for each Typha with Common Name
typha-serverand extended key usage
Configure each Typha with:
CAFilepointing to the certificate authority certificate
ServerCertFilepointing to that Typha's certificate
ServerKeyFilepointing to that Typha's key
Configure each Felix with:
TyphaCAFilepointing to the Certificate Authority certificate
TyphaCertFilepointing to that Felix's certificate
TyphaKeyFilepointing to that Felix's key
For a SPIFFE-compliant deployment you can follow the same procedure as above, except:
Choose SPIFFE Identities to represent Felix and Typha.
When generating leaf certificates for Felix and Typha, put the relevant SPIFFE Identity in the certificate as a URI SAN.
ClientURISANparameter to the SPIFFE Identity for Felix that you use in each Felix certificate.
TyphaURISANparameter to the SPIFFE Identity for Typha.
For detailed reference information on these parameters, refer to: