Govern TLS Certificates in a Kubernetes Cluster

Filed Under: Random
TLS Certificates

Hello, readers! This article talks about Governing TLS Certificates in a Kubernetes Cluster.

So, let us begin!! 馃檪

Trusting a TLS approver in a Kubernetes Cluster

When it comes to hosting applications in the form of containers over the Kubernetes architecture, below is the observation-

It is obvious that the application pods would be having some external configuration to run their application on the web portals.

Having said that, in the scenario of trusting a custom or different Certificate Authority (CA) from within an application pod would definitely require some extra configurations across it.

For the same, we would need to add that particular custom CA to the list of CA certificates that the cluster’s TLS client or server would trust and comply with.

For example, consider a goLang integrated application. Then we will be needing to parse the CA certificate. And then add them to the RootCAs in the tls.config structure.

We can then make these CA certificates available as a ConfigMap for the pods to refer to and use.

Creating a Certificate Signing Request

We will now be creating a Certificate Signing Request and then this request would move to the Kubernetes API.

Let us now have a look at the way of generating a Certificate Signing Request-

kind: CertificateSigningRequest
  name: demo-csr
  request: $(cat server.csr | base64 | tr -d '\n')
  - digital signature
  - key encipherment
  - server auth

In the above example, we have requested the CSR with a digital signature, key encipherment, and a server auth which will be duly signed by the聽signer.

The server.csr has to be created in a base64 encoded format as shown below-

We make use of the cfssl tool to generate the private certificate and a Certificate Signing request.

cfssl genkey - | cfssljson -bare server
  "hosts": [
    "service IP",
    "pod IP"
  "CN": "",
  "key": {
    "algo": "ecdsa",
    "size": 256
  "names": [
      "O": "system:nodes"

The above code generates two files:

  1. server.csr – It contains the PEM encoded certificate request with the details around the service.
  2. server-key.pem : It contains the PEM encoded key to the certificate.

Once we create the Certificate Signing Request, it becomes available to view in the Pending state.

kubectl describe csr demo-csr


Name:                   demo-csr
Labels:                 <none>
Annotations:            <none>
CreationTimestamp:      Tue, 21 Mar 2017 07:03:51 -0700
Requesting User:
Status:                 Pending
        Common Name:
        Serial Number:
Subject Alternative Names:
        DNS Names:
        IP Addresses:
Events: <none>

Approving a Certificate Signing Request

Usually, a Kubernetes Administrator has the authority to manually approve or deny any Certificate Signing Request.

For the same, we need to consider the following scenarios-

  • Usually, the subject of the Certificate Signing Request solely controls the private key that is used to sign the CSR.
  • The above step enables to address the threat of any other or a third party subject.
  • Also, the subject of CSR is by default authorized to act in the requested content of the subject.

Looking at the above scenario, a Kubernetes Administrator can approve/deny the CSR using the below commands-

kubectl certificate approve CSR-name
kubectl certificate deny CSR-name


By this, we have approached the end of this topic. Feel free to comment below, in case you come across any questions.

For more such posts related to Docker and Kubernetes, Stay tuned with us.

Till then, Happy Learning!! 馃檪

Generic selectors
Exact matches only
Search in title
Search in content