Accessing secret-id specific metadata from identity template

Vault
1

So I was hoping to have one approle with multiple secret_ids, and be able to put out an oidc/jwt token based on that secret_id. Since the metadata is already in there, it looked promising and I came up with this secret_id payload:

{
  "metadata": "{ \"hostname\": \"$SERVER_NAME\", \"client_hostname\": \"$SERVER_NAME-client\" }",
  "cidr_list": "${IP_ADDR}/32",
  "token_bound_cidrs": "${IP_ADDR}/32",
  "num_uses": 5,
  "ttl": "60m"
}
EOF

Where I set the IP and hostname, respectively. This works as intended, and when restarting my cluster auto-configuration attempts, I realized that something was wrong. I set up this oidc role:

vault write identity/oidc/role/consul-auto-config ttl=10m key="oidc-key-1" client_id="consul-cluster-dc1" template='{"consul": {"hostname": {{identity.entity.aliases.auth_approle_xyzzy.metadata.client_hostname}} } }'

Which worked… Until more machines started to come up. Turns out, that the client_hostname metadata I added seems to get set to a merged value on the entity, and it doesn’t lookup the client_hostname from the secret_id metadata (which I was hoping for).

Now, I can of course add one approle per machine to get this whole bootstrapping process up and running, but before I do that: Is there any way to bend the templating thing to my will, and use one approle but get at the metadata in the specific secret_id somehow?

2

You’ll need to go with the one approle per machine approach.

The reason for this is that Vault is built to see each approle as an “account”, and multiple secret-ids per approle as different passwords for that account - and all of the approle auth method’s interaction with the Vault Identity system (of which the OIDC provider is part) is structured around that model.

In your environment, you would create multiple secret-ids only as a means to rotate the secret belonging to a particular host.

3

Aw, that’s somewhat disappointing, but thanks for the answer nonetheless, it should be easy enough, although not as elegant. Thanks for the pointer!