possibility to use token role when creating child token

[rpasche]

This PR allows you to - optionally - use a predefined token role when requesting new child tokens while limiting policies.

Instead of requiring the requesting AppRole to have to include all possible token_policies (and then just using a subset), the requesting AppRole can just be granted a single policy again granting to create a token using a predefined token role (which can request other policies NOT already included within the token_policies)

Testing done

Sorry, I still need to try to write tests. I am not really a Java developer (getting it all running - and debugging - was already quite a pain for me. I will try to add those.

But what I did:

• setup a vault dev mode (with rudiment script)

#!/usr/bin/env bash

vault server -dev -dev-root-token-id=dev-only-token &
echo $! > .vault.pid

export VAULT_TOKEN=dev-only-token
export VAULT_ADDR=http://localhost:8200

# enable approle auth method
vault auth enable approle

# enable dummy-secrets
vault secrets enable -path=dummy-secrets -version=2 kv

# create jenkins approle
vault write auth/approle/role/jenkins \
  token_type=service \
  secret_id_ttl=43200m \
  token_ttl=10m \
  explicit_max_ttl=30m \
  secret_id_num_uses=0 \
  token_policies="jenkins_main"

# create token role
vault write auth/token/roles/jenkins token_type=batch allowed_policies="dummy1,dummy2" orphan=true renewable=false disallowed_policies="root,namespace-admin"

# get the role-id and echo that
echo "The role-id for 'jenkins' is: $(vault read -format=json auth/approle/role/jenkins/role-id | jq -r '.data.role_id') ..."

echo "The secret-id for 'jenkins' is: $(vault write -f -format=json auth/approle/role/jenkins/secret-id | jq -r '.data.secret_id') ..."

# policies

vault policy write dummy1 - <<EOF
path "dummy-secrets/data/*" {
  capabilities = ["read"]
}

path "dummy-secrets/metadata/*" {
  capabilities = ["read"]
}
EOF

vault policy write dummy2 - <<EOF
path "dummy-secrets/data/*" {
  capabilities = ["create", "update", "patch", "delete"]
}

path "dummy-secrets/metadata/*" {
  capabilities = ["create", "update", "patch", "delete"]
}
EOF

vault policy write jenkins_main - <<EOF
path "/auth/token/create/jenkins" {
  capabilities = ["create", "update"]
}
EOF

# create dummy secret dummy1 (in dummy-secrets)
vault kv put -mount=dummy-secrets dummy1 username=foo password=bar

echo "Done."

So the AppRole jenkins is created with only policy jenkins_main assigned via token_policies. jenkins_main itself allows to create child tokens using the jenkins token role. When trying to create child tokens, only dummy1 or dummy2 maybe be used (possibility to use globbing). So in this example, dummy1 can read the secret at dummy-secrets/data/dummy1

Configure global Vault plugin by just providing the url, the AppRole and the path prefix dummy-secrets.

With that, using the slightly adjusted example from the README in a pipeline

node {
    // define the secrets and the env variables
    // engine version can be defined on secret, job, folder or global.
    // the default is engine version 2 unless otherwise specified globally.
    def secrets = [
        [path: 'dummy1', secretValues: [
            [envVar: 'username', vaultKey: 'username'],
            [envVar: 'password', vaultKey: 'password']
            ]
        ]
    ]

    // optional configuration, if you do not provide this the next higher configuration
    // (e.g. folder or global) will be used
    def configuration = [policies: "dummy1", role: "jenkins"]

    // inside this block your credentials will be available as env variables
    withVault([configuration: configuration, vaultSecrets: secrets]) {
        sh 'echo Username: $username'
        sh 'echo Password: $password'
    }
}

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[rpasche]

Anyone some interest?