DEV Community

Wycliffe A. Onyango
Wycliffe A. Onyango

Posted on

100 Days of DevOps: Day 62.

#devops #kubernetes #linux #containers

Successfully Securing License Keys in Kubernetes with Secrets

I have successfully implemented a secure method for handling licensed tooling within their Kubernetes cluster by leveraging Kubernetes Secrets. This task focused on creating a generic secret from an existing file and configuring a new Pod to securely consume that secret data by mounting it as a file inside the container.

The execution followed a two-step process, which was verified through terminal outputs confirming the secure deployment.

Step 1: Creating the Kubernetes Secret

The first requirement was to secure the license key contained within the /opt/news.txt file on the jump host. This was accomplished using a kubectl create secret generic command, which directly converts the file's contents into a Kubernetes Secret object.

kubectl create secret generic news --from-file=/opt/news.txt
# Output: secret/news created
Enter fullscreen mode Exit fullscreen mode

This command created a Secret named news, holding the license key data, thus fulfilling the requirement for secure storage within the cluster.

Step 2: Deploying the Pod and Consuming the Secret

The next phase involved deploying a Pod named secret-nautilus and configuring it to access the newly created secret. The Pod specification included a container named secret-container-nautilus using the debian:latest image and a persistent sleep command to keep it running.

Crucially, the Pod was configured to consume the news secret by mounting it as a volume at the required path, /opt/demo, inside the container.

Pod YAML (secret-nautilus.yaml)

The following YAML manifest was used to define and deploy the Pod:

apiVersion: v1
kind: Pod
metadata:
  name: secret-nautilus
spec:
  containers:
  - name: secret-container-nautilus
    image: debian:latest
    # Use sleep command to keep the container running
    command: ["/bin/bash", "-c", "sleep 3600"]
    volumeMounts:
    - name: news-volume
      mountPath: /opt/demo
      readOnly: true
  volumes:
  - name: news-volume
    secret:
      secretName: news
Enter fullscreen mode Exit fullscreen mode

This configuration ensures the container runs the required image, stays in a running state, and mounts the Secret data precisely at /opt/demo. The manifest was applied using kubectl apply -f secret-nautilus.yaml.

Verification of Secure Access

To confirm the successful implementation, the team performed a direct verification by executing commands inside the running container.

First, the successful running status was confirmed:

kubectl get pods secret-nautilus
# Output: secret-nautilus  1/1     Running   0           38s
Enter fullscreen mode Exit fullscreen mode

Next, listing the contents of the mounted directory showed the secret data was accessible as a file:

kubectl exec -it secret-nautilus -c secret-container-nautilus -- ls -l /opt/demo
# Output: lrwxrwxrwx 1 root root 15 Oct 5 00:33 news.txt -> ..data/news.txt
Enter fullscreen mode Exit fullscreen mode

Finally, reading the contents of the file proved the license key was correctly consumed:

kubectl exec -it secret-nautilus -c secret-container-nautilus -- cat /opt/demo/news.txt
# Output: 5ecur3
Enter fullscreen mode Exit fullscreen mode

The retrieval of the placeholder license key (5ecur3) confirmed that the sensitive data is correctly isolated in a Kubernetes Secret and securely presented to the required container, successfully meeting all project requirements and establishing a reliable pattern for managing licensed tools in future deployments.

Top comments (0)