App Role "self renewal" - is it possible to allow 'write' but not alter any settings?

Vault
1

I’m currently using non-expiring app roles (secret_id_ttl) for “host/server/application level authentication to vault”. I’d like to move this to a model where the secret ids have a more reasonable expiration, and require that they “renew/cycle" themselves periodically to keep valid.

Since secret id is not a token, there is no ‘renew’ operation, but the thought was that I’d have the approle do a “write” against the auth/approle/role/ROLENAME/secret-id endpoint.

Can I safely allow write against that path from itself? I’m waiting to make certain that I’m not giving it any ability to alter it’s configuration, only to do a secret-id rotation.

Alternatively, is there a better way to accomplish this? I suppose technically I could seed an actual token to the hosts, and use the standard renew functionality with the token.

Thoughts?

2

You shouldn’t need write, or at a minimum don’t need write on on the secret-id endpoint where the clients need access.

Just did a quick test to verify.

  • Logged in as a user with a simple read/update policy on the approle secret-id and role-id endpoints
  • Reading role-id succeeded
  • Writing secret-id succeeded
  • Writing the config for the role itself failed

Example policy approleuserid:

path "auth/approle/role/jenkins/role-id" {
  capabilities = ["read"]
}

path "auth/approle/role/jenkins/secret-id" {
  capabilities = ["update"]
}

Example output:

vault login -method=userpass user=jfrap

Key                    Value
---                    -----
token                  hvs.CAESIAO...snip...1sbU1nQkZtZW0
token_accessor         BRbItxI4mDSA38yFKNPUMtnN
token_duration         768h
token_renewable        true
token_policies         ["approleuserid" "default"]
identity_policies      []
policies               ["approleuserid" "default"]
token_meta_username    jfrap

vault read auth/approle/role/jenkins/role-id
Key        Value
---        -----
role_id    bf77e7a2-b2c6-ead3-b99c-eea53b7d3e9e

vault write -force auth/approle/role/jenkins/secret-id
Key                   Value
---                   -----
secret_id             ac1ccd3e-923b-41a4-6964-05aade5f96b1
secret_id_accessor    f30ee52a-224b-0d49-3159-d381ffdaaaa2
secret_id_num_uses    0
secret_id_ttl         0s

vault write auth/approle/role/jenkins token_policies="jenkins" \
    token_ttl=1h token_max_ttl=8h
Error writing data to auth/approle/role/jenkins: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/auth/approle/role/jenkins
Code: 403. Errors:

* 1 error occurred:
        * permission denied

I expected the permission denied on the role config command since that path is not part of the policy.

3

The missing piece is that the above secret-id has an unlimited TTL. It’s valid forever.

What I’m trying to address is the combined recommendation of “don’t have a forever <secret/token/identity>” and “applications/services should auth with approle if they can’t use environment identity (k8s/instances/etc.)”.

If you create your approle secret-id with a limited ttl - say 30d or even shorter – the goal of this request is “how to renew that to get a new secret id”. If it was a token endpoint, then can just renew, but there is no equivalent operation for the secret id - other than generating a new one.

If I go “central push” model - I can certainly have something regularly go and push a new secret-id out to every location where it’s being used, but that makes that central location super-privileged.

4

Ahh yes - sorry for misinterrupting. You do need some means to rotate the role id and secret id since you can’t renew it in that scenario.