Vault – Authentication methods. - DevOps

In this post, I want to show you the 4 most common authentication types for Vault.

Token (Default)
AppRole
LDAP
TLS
Username and Password.

I won’t go into the details of each of them, as that would generate huge posts, for that it’s worth looking for more specific materials. For now I will just show you how to configure and use it.

For all the examples below, I will use the same policy for demonstration and the same KV for reading.

vault secrets enable -path=secret kv-v2

Success! Enabled the kv-v2 secrets engine at: secret/


#######################################################################################################################


vault kv put secret/infrastructure/jenkins/test-secret01 username="usr-test01" pwd="1234qwer"

================== Secret Path ==================
secret/data/infrastructure/jenkins/test-secret01

======= Metadata =======
Key                Value
---                -----
created_time       2025-02-03T18:01:02.576993738Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

#######################################################################################################################


vault policy write jenkins -<<EOF
path "secret/data/infrastructure/jenkins/*" {
  capabilities = [ "read" ]
}
EOF

You will see that at the end, you will have a list of enabled authentications like this:

vault auth list
Path         Type        Accessor                  Description                Version
----         ----        --------                  -----------                -------
approle/     approle     auth_approle_1ad709cc     n/a                        n/a
cert/        cert        auth_cert_cf959dec        n/a                        n/a
ldap/        ldap        auth_ldap_2605ea3b        n/a                        n/a
token/       token       auth_token_eef9787e       token based credentials    n/a
userpass/    userpass    auth_userpass_58cbd79f    n/a                        n/a

The Token authentication method is what is already enabled by default in the Vault installation, the “admin” user uses a token to authenticate, so no specific work is required.

But, I will show you how to create a token, with a TTL of 24 hours assigned to a policy.

In the example below, I will create a token and assign the jenkins policy (policy created in the post: https://devops-db.com/jenkins-vault-integration/), log in and do a simple get.

vault token create -policy=jenkins -period=24h

Key                  Value
---                  -----
token                hvs.CAESILUXD_g7btsikCiSR-RHHTCJh9hIzB7EUfzcnLFh50uwGh4KHGh2cy5vNVZrelgxY2FYMndFSFlscFdBZVZpOXA
token_accessor       3ybIytXc3wIjYwj6zARmS75O
token_duration       24h
token_renewable      true
token_policies       ["default" "jenkins"]
identity_policies    []
policies             ["default" "jenkins"]

With that, let’s log in and do a Get test. Please note that in 24 hours this Token will no longer work.

vault login hvs.CAESILUXD_g7btsikCiSR-RHHTCJh9hIzB7EUfzcnLFh50uwGh4KHGh2cy5vNVZrelgxY2FYMndFSFlscFdBZVZpOXA
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                hvs.CAESILUXD_g7btsikCiSR-RHHTCJh9hIzB7EUfzcnLFh50uwGh4KHGh2cy5vNVZrelgxY2FYMndFSFlscFdBZVZpOXA
token_accessor       3ybIytXc3wIjYwj6zARmS75O
token_duration       23h59m43s
token_renewable      true
token_policies       ["default" "jenkins"]
identity_policies    []
policies             ["default" "jenkins"]

#######################################################################################################################

vault kv get secret/infrastructure/jenkins/test-secret01
================== Secret Path ==================
secret/data/infrastructure/jenkins/test-secret01

======= Metadata =======
Key                Value
---                -----
created_time       2025-02-03T18:01:02.576993738Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

====== Data ======
Key         Value
---         -----
pwd         1234qwer
username    usr-test01

The AppRole auth method allows machines or apps to authenticate with Vault-defined roles. The open design of AppRole enables a varied set of workflows and configurations to handle large numbers of apps. This auth method is oriented to automated workflows (machines and services), and is less useful for human operators. We recommend using batch tokens with the AppRole auth method.

We already created an approle in the Jenkins x Vault post, but I’ll replicate the steps here:

Once logged in with an administrative account, we first need to enable the approle authentication type:

vault auth enable approle
Success! Enabled approle auth method at: approle/

With that enabled, let’s create an approle called jenkins-role. This approle will be used in Jenkins for integration with Vault.
token_num_uses (integer: 0) – The maximum number of times a generated token can be used (no lifetime); 0 means unlimited. If you require the token to have the ability to create child tokens, you will need to set this value to 0.

secret_id_num_uses (integer : 0) – Number of times any particular SecretID can be used to fetch a token from this AppRole, after which the SecretID will by default expire. A value of zero will allow unlimited uses. As always, this option can be overridden by the ‘num_uses’ request field when generating a SecretID.

vault write auth/approle/role/jenkins-role token_num_uses=0 secret_id_num_uses=0 policies=jenkins

Success! Data written to: auth/approle/role/jenkins-role

See that we created the approle and indicated a Policy called: jenkins.
We haven’t defined it yet, we’ll first create the Secrets structure and then it will be possible to create the policy.

We now need to read the jenkins-role information and get the role-id, leave it written down aside, as we will need it in the login.

vault read auth/approle/role/jenkins-role/role-id

Key        Value
---        -----
role_id    166b7809-2fc6-1825-7620-f2dff60bcbb1

The next step is to generate a secred_id for this approle, in the same way, keep this information securely written down, as it will be needed in the login.

vault write -f auth/approle/role/jenkins-role/secret-id
Key                   Value
---                   -----
secret_id             3c3ae697-433b-d702-c6fa-7b758f66ba66
secret_id_accessor    84aa8223-56cd-8cb1-7996-f6e6f92d001d
secret_id_num_uses    0
secret_id_ttl         0s

One different point here is that, it is not possible to login directly via CLI or API with AppRole. To test via cli you need to generate a token for this approle. See the Jenkins and Python posts that this step is not necessary in other situations.

The first step is to generate a Jenkins approle token so we can log in and test getting the secret.
Remember the role_id and secret_id that was generated at the beginning of this post? At the time of creating the approle, we will need them now. (again later in Jenkins configuration)

$ vault write auth/approle/login role_id=166b7809-2fc6-1825-7620-f2dff60bcbb1 secret_id=3c3ae697-433b-d702-c6fa-7b758f66ba66

Key                     Value
---                     -----
token                   hvs.CAESIJ9Tuv0b5HtdB2wc9WqVtQo7mR8Lbna1NZ_NdO5q5whgGh4KHGh2cy5aaDFzUjBMem1CRkNta2pVRlF4elBPNGI
token_accessor          OXwjtBO7Gh7dH9MTlD0ZVMF6
token_duration          768h
token_renewable         true
token_policies          ["default" "jenkins"]
identity_policies       []
policies                ["default" "jenkins"]
token_meta_role_name    jenkins-role


#######################################################################################################################


vault login hvs.CAESIJ9Tuv0b5HtdB2wc9WqVtQo7mR8Lbna1NZ_NdO5q5whgGh4KHGh2cy5aaDFzUjBMem1CRkNta2pVRlF4elBPNGI

Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.


#######################################################################################################################


vault kv get secret/infrastructure/jenkins/test-secret01

================== Secret Path ==================
secret/data/infrastructure/jenkins/test-secret01

======= Metadata =======
Key                Value
---                -----
created_time       2025-02-03T18:01:02.576993738Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

====== Data ======
Key         Value
---         -----
pwd         1234qwer
username    usr-test01

This authentication method has also been described in post https://devops-db.com/vault-ldap-integration/, as it is a slightly more complicated process, it is worth visiting the post.

TLS authentication in Vault, using a certificate, is another very common and secure way to authenticate services for example.

Info Box

To have this type of authentication working, Vault must have TLS/HTTPS enabled and working.
https://devops-db.com/vault-enabling-https/

The first step to using this authentication method is to generate a certificate.
Important: The CN (Common Name) must be filled in the certificate, or we will get an error in the Vault “missing name in nickname” and it will not be possible to log in.

Also in the HTTPS configuration post, I will use a configuration file to generate the certificate. https://github.com/faustobranco/devops-db/blob/master/vault/certificate.conf

We will use the certificate to create the authentication entry (we could say that it would be something like a user). And then both the public and private key to login. So have the generated files on hand.

openssl req -x509 -batch -nodes -newkey rsa:2048 -keyout auth_vault_key.pem -out auth_vault_cert.pem -config certificate.conf -days 9999

..+...+.....+......+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*...+....+...........+.+........+.+...+........+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*......................+......+.+...+..+..................+.........+...+...+......+...+.......+...........+..................+...................+..+...+.+..+....+........+.+..+....+.........+..+....+...+..+...+.+......+.....+.+...+..+...+.+......+..+...+.......+..................+.........+..................+...+...+.....+....+...+...+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
...+.....+.+.....+...+......+.+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*..+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*.....+......+....+..+.........+...................+.....+..........+.....+.+......+.........+......+.....+....+.....+....+..+...+.............+........+................+...+........+....+...............+.....+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----

Let’s enable the cert authentication type in Vault.

vault auth enable cert

Success! Enabled cert auth method at: cert/

And now let’s create an authentication entry, like I said, something that would look like a user.

It’s that simple, see that the assigned policy is Jenkins, to take advantage of the policy already created in other posts and in this one.

vault write auth/cert/certs/auth_vault_01 \
display_name=auth_vault_01 \
policies=jenkins \
certificate=@auth_vault_cert.pem

Success! Data written to: auth/cert/certs/auth_vault_01

We log in.

vault login -method=cert -client-cert=auth_vault_cert.pem -client-key=auth_vault_key.pem name=auth_vault_01

Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

And now a reading test.

vault kv get secret/infrastructure/jenkins/test-secret01
================== Secret Path ==================
secret/data/infrastructure/jenkins/test-secret01

======= Metadata =======
Key                Value
---                -----
created_time       2025-02-03T18:01:02.576993738Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

====== Data ======
Key         Value
---         -----
pwd         1234qwer
username    usr-test01

Username and password is the most common method used, not the most secure, but it can still be useful when we do not have integrated LDAP.

First, we need to enable the userpass authentication type.

vault auth enable userpass

Success! Enabled userpass auth method at: userpass/

Then create a user with a password and assign the jenkins policy.

vault write auth/userpass/users/test_user \
    password=1234qwer \
    policies=jenkins
    
Success! Data written to: auth/userpass/users/test_user

So let’s log in and validate by doing a get on a KV.

vault login -method=userpass username='test_user' password='1234qwer'

Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.


#######################################################################################################################


vault kv get secret/infrastructure/jenkins/test-secret01

================== Secret Path ==================
secret/data/infrastructure/jenkins/test-secret01

======= Metadata =======
Key                Value
---                -----
created_time       2025-02-03T18:01:02.576993738Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

====== Data ======
Key         Value
---         -----
pwd         1234qwer
username    usr-test01

Vault – Authentication methods.

Info Box

By devops-db.com

Related Post

You Missed

Vault – Secrets Integration with Kubernetes.

Vault – File storage as secret.

Ansible – Read Vault secrets.

Terraform – Read Vault secrets