Challenge 48 ☆☆

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

Sealed Secret with Accessible Key

In this challenge, you will explore the usage of kubernetes Sealed Secret. Sealed Secrets are a way to encrypt your Kubernetes secrets and store them safely, even in a public repository. However, improper handling of these secrets can still pose a security risk.

A Developer has accidentally made the private key for decrypting the sealed secrets accessible within the same repository that contains the sealed secret. Your task is to find and decrypt teh sealed secret using the accessible private key.

Can you find and decrypt the sealed secret to reveal the sensitive information?

Answer to solution :

This challenge can be solved using the following ways:

  • Decrypt the sealed secret using the accessible private key found in the repository:

    1. Clone the repository containing the challenge files.

    2. Locate the sealed-challenge48.json file in the repository.

    3. Find the unencrypted private key file named main.key in the repository.

    4. Use the kubeseal tool to decrypt the sealed secret: kubeseal --recovery-unseal --recovery-private-key k8s/main.key < k8s/sealed-challenge48.json > unsealed-secret.yaml

    5. unsealed-secret.yaml is unsealed secret is base64 encoded, we need to decode it and the resulting text will be the answer.

  • Get access to the secret directly:

    1. with access to the cluster, do kubectl get secret challenge48secret -o yaml

    2. decode the secret.

Note: Ensure you have a valid Kubernetes configuration and access to a Kubernetes cluster. If you are running this on a hosted environment where you do not have direct access to the Kubernetes cluster, ask the organizer of the hosted solution to execute the commands for you and return the results.

Why Proper Handling of Sealed Secrets is Important?

Sealed Secrets provide a way to encrypt your Kubernetes secrets and store them safely, even in public repositories. However, improper handling and misconfiguration can lead to serious security vulnerabilities.

If the private key used to decrypt the sealed secrets is exposed or accessible within the same repository, it nullifies the security provided by the Sealed Secrets. Anyone with access to the repository can decrypt the secrets, leading to potential data breaches and unauthorized access.

Let’s consider an example:

  1. Imagine a scenario where a developer stores the private key used for Sealed Secrets decryption in the same repository:

    • The repository contains sealed-challenge48.json and the private key main.key.

  2. This situation is analogous to locking a door and leaving the key under the doormat:

    • An attacker can easily find the key and unlock the door, gaining access to everything inside.

To prevent such issues, it is crucial to ensure that private keys are stored securely and separately from the encrypted data. Always follow best practices for secret management and avoid exposing sensitive information in your repositories.

Food for thought on sealed secrets Sealed secrets have some issues even when you keep the private key away from the repository. 1. If you don’t configure RBAC or ABAC correctly, anyone can still access the secret when they can access the cluster. 2. Sealed secrets are a type of hardcoded secret, which makes auditing difficult. Who or what accessed a secret, and from where? 3. If you’re going to rotate your sealing key, you’ll need to rotate all of your secrets encrypted with said key - potentially across dozens of repositories (as to why: see the git history challenge). How will you find them? And how do you identify which secrets were encrypted with what key? How do you make the previous version of a secret securely accessible? 4. Sealed secrets can be subject to offline attacks, the viability of which depends on what you used to encrypt the secrets. Can you think of improper encryption schemes?


Previous
Go the main page
Next
0