SSL/TLS Termination [GL ARC]
SSL = Secure Sockets Layer
TLS = Transport Layer Security
Strictly speaking SSL it not used any more. SSL is an outdated specification which had been superseded by TLS in 1999. SSL 2.0 was deprecated min 2011, SSL 3.0 in 2015. So when speaking about SSL nowadays we usually mean TLS.
TLS ensures that data is transferred over an encrypted connection and thus cannot be read while on the wire. Ideally, all network communication is encrypted - but as always, encryption comes with a price: either real money and/or implementation and maintenance efforts.
There are different levels of possible trade-offs. For a Vidispine Enterprise MAM Solution the current implementation does TLS termination at the edge of the Kubernetes cluster. Cluster-internal traffic is unencrypted.
The following sections assume that you are familiar with Load Balancing and MetalLB [GL ARC] and with the basic concepts of SSL/TLS.
TLS Termination On Ingress Controller
The default product setup for Vidispine Enterprise MAM is to do TLS termination on the ingress controllers. When using MetalLB in layer-2 mode this is the preferred way to go.
TLS Termination On External Load Balancer
When an external load balancer is used, TLS termination may be done by the load balancer. As updating the certificates is a regular task, this can then be done w/o touching the Kubernetes cluster.
The key building block for TLS termination are certificates. They serve two major purposes:
allow encryption of the transmitted data;
ensure that the client really is talking to the server it wants to.
For TLS termination of web frontends to work with modern browsers, the certificates must meet the following criteria:
The certificates must be issued for the exactly the hostname used in the browser. E.g. accessing the URL https://vidispine.company.com/ requires a certificate for vidispine.company.com. The browser URLs https://vidispine or https://10.17.45.28 won’t work. Please note that - although certificates support multiple hostnames - Vidispine Enterprise MAM currently only supports a single host name per endpoint for TLS termination.
The certificates must contain the hostname as „Subject Alternative Name“ (SAN).
The certificates must support the key usages
dataEnciphermentas well as the enhanced key usage
The issuing CA must be a trusted root CA on all relevant computers. This can either be achieved by using one of the generally accepted CAs; or you have to install the complete certificate chain of the issuing CA as trusted root certificate on all computers.
Self-signed certificates may be used, but the self-signed certificate must be installed on all computers as trusted certificate.