Challenge 45 ☆☆☆☆

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

Vault subkey challenge

Sometimes, all you want to do is have that concise entry in your secrets management system. So, what about storing your username and password in the same entry? We tried doing that but got into a new problem! With Hashicorp Vault, you can set up policies to allow access to a subkey (Which is the key to the value of your secret). Can you find the very random username we set up for this challenge?

Answer to solution :

This challenge can be solved using the following steps:

  1. Find the secret with the commandline

    • use kubectl exec vault-0 -n vault — vault kv get secret/wrongsecret to find the data.

  2. Find the Secret in Vault using the logged root token:

    • When you setup the K8s environment, the script tells you the value of the root token as below:

      Key                  Value
---                  -----
token                s.Jqka4lSy8ayQw2LFsvyAgnTI
token_accessor       HEr9RYa3OcZNDOHeFRXIMYCV
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

    • Use the token to login into Vault exposed at port 8200

    • Take a look around: can you find the location of the secret in the secrets overview?

  3. Find the secret as the SRE member

    • go to the vault web interface

    • login with in with username "helper" and password "foo"

    • find the actual secret.

Why putting sensitive data as keys is a bad idea

Sometimes, people reason that less sensitive data should be stored as a subkey of the actual secret. That way, both a username and a password, for instance, can be combined in a single entry. In many cases, these secrets are equally important and should get equal protection as the secret (e.g. the password) itself. And in Vault’s case, you can access a subkey (E.g., the username), but not the secret value itself (e.g., the password), which would already leak the username.

We often don’t want to give read access to secrets to our employees, but we do want to provide read access to subkeys instead. If any secret is stored in the subkeys, that secret is then compromised internally.


Previous
Go the main page
Next
0