Ingress control on Applications requiring Keystore and truststore on Kubernetes clusters. 

Keys and certificates are used to secure data by using the public key to encrypt and the private key to decrypt. A certificate is used as a stamp of authority. It can include the public key. The certificate then becomes usable to secure the ends of a channel such as https.  Applications tend to require a key and a certificate in their configuration. Sometimes they require keystores and truststores as alternative formats. Keystores is a combination of key and certificate. It is made available in the form of a file with pfx extension or p12 extension. The truststores is merely a collection of certificates to be trusted. It could include a certificate chain if the certificates are signed. The generation of these bundles is specified in the RFC and performed with command line tools such as openssl and keytool. Not all languages have libraries to generate these bundles  and therefore the logic to generate the bundle is not part of many software development kits (SDK). 

Kubernetes is a system for managing the containerized applications. It facilitates deployment and scaling. As part of deployment, applications have to set up accounts, passwords and other secrets. These secrets are necessary to be made available as files and environment variables for the deployment to go through. 

The infrastructure provides a standard way of keeping these secrets. The secret is specified declaratively and then subsequently made available to the application. It can also be specified dynamically by the application code. 

The secret is kept in the form of base64 encoded data. The secret can be written out a file on mounted volume for use by the application. In such case, it is preferable to mark the volume as read only. The secret can be accessible from any pod in the system 

Kubernetes (aka K8s) applications are deployed with the help of an SDK called the operator-sdk. A Kubernetes operator is a controller that takes its resource definitions for an application and reconciles the container configuration with the definitions. For example, an upgrade would be defined by the source and destination version numbers and associated locations to permit the controller to take the necessary actions. Definitions are for resources specific to the applications and they are called custom resource definitions. They are written in Yaml – a language for definitions and maintained in a folder called deploy under the root project folder. The other folder is for the logic in the controller and written in Go language. The operator logic has code for apis and controller. As with all logic, there is also code for the entry point invocation. Moreover, there is a Dockerfile created by packaging the operator into a Docker image that deploys the operator and an associated account to run it. Writing the operator is facilitated with the help of an operator software development kit which is available as a command line tool that generates the scaffolds necessary for the api and the controller. 

Kubernetes takes keys, certificates, keystores and truststores as secrets. For example, we can specify:  

kubectl create secret tls ${CERT_NAME} --key ${KEY_FILE} --cert ${CERT_FILE}  

An ingress controller controls the traffic into the Kubernetes cluster. Typically, this is done with the help of nginx. An Ingress-nginx controller can be configured to use the certificate.  

Nginx provides the option to specify a –default-ssl-certificate.  The default certificate is used as a catch-all for all traffic in the server. Nginx also provides a –enable-ssl-passthrough feature This bypasses the nginx and the controller instead pipes it forward and backward between the client and backend. If the virtual domain cannot be resolved, it passes to the default backend.  

Therefore the two steps required to secure the ingress controller include the following: 

1. Use a library such as cert-manager to generate keys and certificates. 

2. Use the generated key and certificates as Kubernetes secrets and generate the keystore and truststore whose location is specified in the SSL configuration of the application.