Programmability using certificates on Kubernetes

 Automations involving certificates on Kubernetes:

The following article describes some of the libraries available to automate workflows involving X509 certificates on Kubernetes. They are typically used to configure endpoints with Transport Layer Security/TLS which adds the https to otherwise http protocol.  Configuring the tls parameters for a service involves a key and a certificate. The generation of certificates including self-signed ones has been tricky even for the common use case.

Problems encountered in secuing TLS include the following:

1) the format required by a Java application might be keystore/truststore based while the key/certificate are standard format

2) the certificates themselves may be self-signed and accepting the certificate on the client side is prerequisite.

3) the generation of a certificate involves a certificate signing request and Kubernetes has core support for creating a request but not a certificate

4) Libraries such as cert-manager that generate custom resource definitions to make the certificates easier to generate require a large number of native Kubernetes to be registered and this is not a straightforward single step in the automation as it is on the command line. A list of these resources can be found under https://github.com/jetstack/cert-manager/releases/download/v0.16.1/cert-manager.yaml

5) Each Kubernetes resource such as service account, role, custom resource and secret require corresponding plain old java objects to be declared for use with the automation. This makes portability of the code rather cumbersome.

5) The certificates generated often do not work because they have attributes that cannot be used in all cases. For example, the class name and subject alternative names are often a source for exceptions in setting up TLS.

6) the generation of key certificate pair has to be such that the domain names for the host on the network can be matched with what is specified in the certificate

7) The key-certificate pair have to be guarded as a Kubernetes secret and the secret cannot be shared across Kubernetes namespaces. This calls for the creation of key-certificate pair in each namespace used with an application.

8) The use of wild card characters to support multiple clients or hosts is not always permitted and requires special case handling.

9) the export of Kubernetes resources used to create a certificate and its import as plain old java objects is faciliated with the combination of Kubernetes openapi library and its corresponding gen library but the applications typically prefer such steps to be one time and manual since the resulting certificate is more portable.

10) Kubernetes makes it easy to change the parameters of a certificate but results in a new signing request and a corresponding redeployment which is easy to do from the command line and harder to do without the cert-manager convenience.

Applications that are restricted from redistributing cert-manager are left to use ready-made certificates. Fortunately, it is easier to pass around certificates within the namespace across pods and services as a Kubernetes secret.