How to: Use KMS Plugin to encrypt Kubernetes data on the pod

Kubernetes secrets are designed to store sensitive information such as keys, passwords, and tokens. KMS plugins run as a consisted pod on a Kubernetes master node. The API server interface utilizes a provider-based mechanism that communicates with the plugin, which liaises with the KMS provider to acquire DEK (Data Encryption Key). The Data Encryption Key is used to decrypt encrypted secrets and encrypt the secrets of the data on the pod within Xelon. Learn here how to use the KMS plugin to encrypt Kubernetes data on the pod.

1. Before you initiate the KMS plugin

• Make sure you have installed a Kubernetes cluster, and the kubectl command-line tool is configured to liaise with your cluster. If you do not have a cluster, you need to create one using a minikube or Kubernetes playgroup such as Katacoda and play with Kubernetes.
• To check the Kubernetes version, enter the kubectl version. Ensure the version is 1.10.0 or higher and use with etcd v3.

Configuring the KMS provider

To configure the KMS provider on the API server, you need to include KMS provider type in the provider array in the encryption configuration file by setting the following command:

• name : Displays the name of the initiated KMS plugin.
• endpoint : The endpoint is a domain socket (UNIX to be specific). It is the listen address of the gRPC server.
• cachesize : The number of DEKs to be cached in the server. DEKs require a call to KMS to unwrap, but if the DEKs are cleared, there is no need to call to KMS to unwrap.
• timeout : the number of seconds the Kube API server should wait for KMS plugin to respond before signaling an error.

2.Encrypting your data with the KMS provider on the pod within Xelon H

To encrypt data on the pod within Xelon HQ:

1. Create a new configuration encryption file using the KMS provider:

   apiVersion: v1
   kind: Config
   clusters:
   - name: "k8s-kms-content-writer-cluster"  
     

2. Set the encryption provider config on the Kube API server to point to the exact location of the configuration file in the Xelon HQ.
3. Restart the entire server

3.Define users, contexts, and clusters (KMS Plugin)

Let's suppose you have a cluster, a development work cluster. Your frontend developers work on a namespace called frontend, and the storage developers work on a separate namespace known as the storage. Note that for the development cluster, access to the cluster requires authentication by a certificate.
The development authentication certificate is deployed in the cluster, which communicates with the API server on the pod within Xelon HQ, which allows secure access to the KMS plugin.

Create a directory known as config-exercise. In the config-exercise directory, generate a file named config with the following content:

apiVersion: v1
kind: Config
clusters:
- name: "k8s-kms-content-writer-cluster"
  cluster:
    server: "https://explicitip/k8s/clusters/c-d8gjl"

A configuration file describes cluster, context, and user. Your config file has the framework to describe the cluster, the user, and the context.

Here is a breakdown of each cluster:

• kind: this pinpoints the type of cluster being initiated by the KMS plugin
• clusters: the cluster breakdown the context being unwrapped ad, in this case, the context is:

Go to your config-exercise directory and add the following cluster to authorize permission:

certificate-authority-data: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJpRENDQ\

VM2Z0F3SUJBZ0lCQURBS0JnZ3Foa2pPUFFRREFqQTdNUnd3R2dZRFZRUUtFeE5rZVc1aGJXbGoKY\

kdsemRHVnVaWEl0YjNKbk1Sc3dHUVlEVlFRREV4SmtlVzVoYldsamJHbHpkR1Z1WlhJdFkyRXdIa\

GNOTWpFdwpOREl3TVRNMU1qTXlXaGNOTXpFd05ERTRNVE0xTWpNeVdqQTdNUnd3R2dZRFZRUUtFe\

E5rZVc1aGJXbGpiR2x6CmRHVnVaWEl0YjNKbk1Sc3dHUVlEVlFRREV4SmtlVzVoYldsamJHbHpkR\

1Z1WlhJdFkyRXdXVEFUQmdjcWhrak8KUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVNMT25BckIwRG9zM\

1VMQ3FzaXlXa2RxSlh1WVlMMitvWXBJOTBWKzBoVApBSjdqYmFPSDRuTjJmVXhaVkEvbWlLdE4xT\

El3TERZemF4K24wNmVZblFsd295TXdJVEFPQmdOVkhROEJBZjhFCkJBTUNBcVF3RHdZRFZSMFRBU\

UgvQkFVd0F3RUIvekFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUI0RUo3c0VsTG8KaWM3RkhXbDJrM\

zgrc0NocXc5NGpkSXlselV0NWt1RkF0d0loQVBPTnBsRlFJQ3k1SWx0b0NCT2V4cm5jY0lLcQo3L\
0dQVEE2dTJXZVZLaGRVCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0="

Add the context details on the configuration file:

users:
- name: "k8s-kms-content-writer-cluster"
  user:
    token: "kubeconfig-user-7z2c2:c4c9r5nbsg58sndkdgmm2twbjjpm6vwb7bjqzqkcknq5dxwnqtd7l4"

contexts:
- name: "k8s-kms-content-writer-cluster"
  context:
    user: "k8s-kms-content-writer-cluster"
    cluster: "k8s-kms-content-writer-cluster"

current-context: "k8s-kms-content-writer-cluster"

Open config file to view the details. This option is an alternative to opening the config file, and you can also use the config view command:

kubectl config --kubeconfig=config-demo view

The final output shows a cluster, two users, and two contexts:

apiVersion: v1
kind: Config
clusters:
- name: "k8s-kms-content-writer-cluster"
  cluster:
    server: "https://explicitip/k8s/clusters/c-d8gjl"
    certificate-authority-data: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJpRENDQ\
      VM2Z0F3SUJBZ0lCQURBS0JnZ3Foa2pPUFFRREFqQTdNUnd3R2dZRFZRUUtFeE5rZVc1aGJXbGoKY\
      kdsemRHVnVaWEl0YjNKbk1Sc3dHUVlEVlFRREV4SmtlVzVoYldsamJHbHpkR1Z1WlhJdFkyRXdIa\
      GNOTWpFdwpOREl3TVRNMU1qTXlXaGNOTXpFd05ERTRNVE0xTWpNeVdqQTdNUnd3R2dZRFZRUUtFe\
      E5rZVc1aGJXbGpiR2x6CmRHVnVaWEl0YjNKbk1Sc3dHUVlEVlFRREV4SmtlVzVoYldsamJHbHpkR\
      1Z1WlhJdFkyRXdXVEFUQmdjcWhrak8KUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVNMT25BckIwRG9zM\
      1VMQ3FzaXlXa2RxSlh1WVlMMitvWXBJOTBWKzBoVApBSjdqYmFPSDRuTjJmVXhaVkEvbWlLdE4xT\
      El3TERZemF4K24wNmVZblFsd295TXdJVEFPQmdOVkhROEJBZjhFCkJBTUNBcVF3RHdZRFZSMFRBU\
      UgvQkFVd0F3RUIvekFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUI0RUo3c0VsTG8KaWM3RkhXbDJrM\
      zgrc0NocXc5NGpkSXlselV0NWt1RkF0d0loQVBPTnBsRlFJQ3k1SWx0b0NCT2V4cm5jY0lLcQo3L\
      0dQVEE2dTJXZVZLaGRVCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0="

users:
- name: "k8s-kms-content-writer-cluster"
  user:
    token: "kubeconfig-user-7z2c2:c4c9r5nbsg58sndkdgmm2twbjjpm6vwb7bjqzqkcknq5dxwnqtd7l4"


contexts:
- name: "k8s-kms-content-writer-cluster"
  context:
    user: "k8s-kms-content-writer-cluster"
    cluster: "k8s-kms-content-writer-cluster"

current-context: "k8s-kms-content-writer-cluster"

The certificate-authority-data is the placeholder of the pathname in the certificate file. Note, you have to change this to match the exact pathname in the certificate file.
You may need to use Base64-encoded data embedded instead of single certificate files. For this, you will need to add a suffix -data to the encryption key like certificate-authority-data.

4.Set the KUBECONFIG environment variable

Setting the kubeconfig environment is essential. So, if you have this file, you need to save it from restoring it later. If your config directory, type the following command:

kubectl config view

The command will display the merged information from the API server in the pod within Xelon HQ.

Clean up

As a last step, return the KUBECONFIG environment variable to its original value. Please note that you need to type the following command to initiate the restoration process of the cluster:

$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED

If you have any question how to us KMS Plugin please let us know! Contact our DevOps free of charge!