Challenge 33 ☆☆

Welcome to challenge Challenge 33. You need to guess the secret that is hidden in Java, Docker, Kubernetes, Vault, AWS or GCP.

Kubernetes StringData or Data?

Kubernetes has 2 types of fields for data in a secret. The StringData contains the plaintext data, while the Data contains the base64 encoded value. So what if you want to swap the StringData value to a Data value in order to secure it further? You don’t have to, as long as you have set up RBAC correctly. After all: both values should not be visible when a secret is listed or described. But what if you move from standard to sealed secrets but don’t migrate all of them? Then it might be good to know that the metadata might contain the actual value of the StringData. Can you find the secret?

Answer to solution :

This challenge can be solved by looking at the metadata of the secret:

  1. looking at it through code

    • locate the secret definition in git (Challenge33.yml)

    • find the secret value in the metadata.

  2. looking at it through getting the secret

    • connect to the k8s cluster with kubectl

    • call kubectl get secret challenge33 -o yaml to get all the required data.

    • Find the secret value in the metadata.

  3. misuse debugging when listing all secrets

    • connect to the k8s cluster with kubectl

    • call kubectl get secrets -v9 to get all the required data

    • Find the secret value in the metadata.

Why you should be careful with migrating secrets

When you update a Kubernetes secret and migrate to another format, the original data is part of the metadata captured in the original configuration. Migration of secrets to "something else" should also include a rotation step to ensure the older (less well-protected) value is now useless.


Previous
Go the main page
Next
0