Skip to main content
Calico Enterprise 3.19 (latest) documentation

Configure encryption and authentication to secure Calico Enterprise components

Connections from Calico Enterprise 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 Enterprise components occur over TLS. The Calico Enterprise components present either an X.509 certificate or a JWT to kube-apiserver so that kube-apiserver can verify their identities.

Connections from Node to Typha (Kubernetes)​

Operator based installations automatically configure mutual TLS authentication on connections from Felix to Typha. You may also configure this TLS by providing your own secrets.

Configure Node to Typha TLS based on your deployment​

For clusters installed using operator, see how to provide TLS certificates for Typha and Node.

For detailed reference information on TLS configuration parameters, refer to:

Calico Enterprise Manager connections

Tigera Calico Enterprise Manager's web interface, run from your browser, uses HTTPS to securely communicate with the Calico Enterprise Manager, which in turn, communicates with the Kubernetes and Calico Enterprise API servers also using HTTPS. Through the installation steps, secure communication between Calico Enterprise components should already be configured, but secure communication through your web browser of choice may not. To verify if this is properly configured, the web browser you are using should display Secure in the address bar.

Before we set up TLS certificates, it is important to understand the traffic that we are securing. By default, your web browser of choice communicates with Calico Enterprise Manager through a NodePort service over port 30003. The NodePort service passes through packets without modification. TLS traffic is terminated at the Calico Enterprise Manager. This means that the TLS certificates used to secure traffic between your web browser and the Calico Enterprise Manager do not need to be shared or related to any other TLS certificates that may be used elsewhere in your cluster or when configuring Calico Enterprise. The flow of traffic should look like the following:

Calico Enterprise Manager traffic diagram

note

the NodePort service in the above diagram can be replaced with other Kubernetes services. Configuration will vary if another service, such as a load balancer, is placed between the web browser and the Calico Enterprise Manager.

To properly configure TLS in the Calico Enterprise Manager, you will need certificates and keys signed by an appropriate Certificate Authority (CA). For more high level information on certificates, keys, and CAs, see this blog post.

note

It is important when generating your certificates to make sure that the Common Name or Subject Alternative Name specified in your certificates matches the host name/DNS entry/IP address that is used to access the Calico Enterprise Manager (i.e. what it says in the browser address bar).

Issues with certificates​

If your web browser still does not display Secure in the address bar, the most common reasons and their fixes are listed below.

  • Untrusted Certificate Authority: Your browser may not display Secure because it does not know (and therefore trust) the certificate authority (CA) that issued the certificates that the Calico Enterprise Manager is using. This is generally caused by using self-signed certificates (either generated by Kubernetes or manually). If you have certificates signed by a recognized CA, we recommend that you use them with the Calico Enterprise Manager since the browser will automatically recognize them.

    If you opt to use self-signed certificates you can still configure your browser to trust the CA on a per-browser basis by importing the CA certificates into the browser. In Google Chrome, this can be achieved by selecting Settings, Advanced, Privacy and security, Manage certificates, Authorities, Import. This is not recommended since it requires the CA to be imported into every browser you access Calico Enterprise Manager from.

  • Mismatched Common Name or Subject Alternative Name: If you are still having issues securely accessing Calico Enterprise Manager with TLS, you may want to make sure that the Common Name or Subject Alternative Name specified in your certificates matches the host name/DNS entry/IP address that is used to access the Calico Enterprise Manager (i.e. what it says in the browser address bar). In Google Chrome you can check the Calico Enterprise Manager certificate with Developer Tools (Ctrl+Shift+I), Security. If you are issued certificates which do not match, you will need to reissue the certificates with the correct Common Name or Subject Alternative Name and reconfigure Calico Enterprise Manager following the steps above.

Ingress proxies and load balancers​

You may wish to configure proxy elements, including hardware or software load balancers, Kubernetes Ingress proxies etc., between user web browsers and the Calico Enterprise Manager. If you do so, configure your proxy such that Calico Enterprise Manager receives a HTTPS (TLS) connection, not unencrypted HTTP.

If you require TLS termination at any of these proxy elements, you will need to

  • use a proxy that supports transparent HTTP/2 proxying, for example, Envoy
  • re-originate a TLS connection from your proxy to Calico Enterprise Manager, as it expects TLS

If you do not require TLS termination, configure your proxy to "pass thru" the TLS to Calico Enterprise Manager.