Skip to main content
Calico Cloud documentation

Configure encryption and authentication to secure Calico Cloud components

Connections from Calico Cloud 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 Cloud components occur over TLS. The Calico Cloud 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 Cloud Manager connections

Tigera Calico Cloud Manager's web interface, run from your browser, uses HTTPS to securely communicate with the Calico Cloud Manager, which in turn, communicates with the Kubernetes and Calico Cloud API servers also using HTTPS. Through the installation steps, secure communication between Calico Cloud 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 Cloud Manager through a NodePort service over port 30003. The NodePort service passes through packets without modification. TLS traffic is terminated at the Calico Cloud Manager. This means that the TLS certificates used to secure traffic between your web browser and the Calico Cloud 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 Cloud. The flow of traffic should look like the following:

Calico Cloud 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 Cloud Manager.

To properly configure TLS in the Calico Cloud 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 Cloud 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 Cloud 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 Cloud 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 Cloud Manager from.

  • Mismatched Common Name or Subject Alternative Name: If you are still having issues securely accessing Calico Cloud 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 Cloud Manager (i.e. what it says in the browser address bar). In Google Chrome you can check the Calico Cloud 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 Cloud 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 Cloud Manager. If you do so, configure your proxy such that Calico Cloud 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 Cloud Manager, as it expects TLS

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