« Previous 1 2 3 Next »
Credential management with HashiCorp Vault
Key Master
Authentication via Tokens and Policies
Authentication against the server relies on tokens by default. When the server was initialized, your root token was already stored in the ~/.vault-token
file. If you want to delete this file or authenticate with another user account, Vault asks for your token with the following command:
$ vault auth
Then you can see information such as the token's lifetime or its applicable policies. On creation, a new token inherits the associated policy of the parent token. When a token is revoked, all child tokens that were created are also revoked. The allocation of a token to policies cannot be changed later. To create a token without additional access options, run the following command when logged in with a root token:
$ vault token-create -policy=default
When you log in with the created token, you will no longer have access to the previously created secret in /secret/secret
. Next, create a policy that grants a token read
rights to the /secret/secret
path and assigns all rights to the associated /secret/secret/
folder. Listing 2 shows a corresponding policy. The policies are formatted in HCL, like the Vault configuration. They describe the respective rights (capabilities) for specified paths. The available rights are create
, read
, update
, delete
, list
, and deny
. For access to specially protected areas, you also have sudo
.
Listing 2
Policy Example
path "/secret/*" { capabilities = ["deny"] } path "/secret/secret" { capabilities = ["read"] } path "/secret/secret/*" { capabilities = ["create", "read", "update", "delete", "list"] }
To add the policy to the policy.hcl
file as ita
, you use the command:
$ vault policy-write ita policy.hcl
Use token-create
to create a new token, as shown above, and replace default
with the newly created ita
policy. The response from the server shows you that the token is now assigned both the default
and the ita
policies. The default
policy is automatic and prevents access to all paths that are not explicitly mentioned.
Setting up External Access
Managing a large number of tokens can quickly mean a huge amount of documentation for the administrator. In addition to the token, Vault offers further options for user authentication. In addition to TLS certificates, LDAP, and other back ends, GitHub can also be used to minimize the maintenance overhead. For this, you first add the authentication back end; then, you configure the organization for the back end – in this case, IT-Administrator
:
$ vault auth-enable github $ vault write auth/github/ config organization=IT-Administrator
For successful access, you have to configure a policy that Vault assigns to users after login. This can be done via GitHub teams within the organization. All members of the administration team are given root access to the server with the following command:
$ vault write auth/github/map/teams/administrators value=root
Logging in as a GitHub user who is a member of the GitHub company group now works with the personal access token stored on GitHub.
$ vault auth -method=github token=<GitHub Personal Access Token>
SSH Login to a Cloud Environment
In today's dynamic cloud environments, administrators need an overview of logins on different machines. This is particularly difficult if the admin team is subject to regular changes. It would be useful if you no longer had to worry about maintaining SSH public keys or distributing and updating shared passwords for administration. Using the example of an Amazon Elastic Compute Cloud (EC2) instance, I will now configure Vault for SSH login (Figure 3). EC2 generates instances based on a template, the Amazon Machine Image (AMI). If this template already contains Vault's SSH back end [3], spontaneous use becomes child's play.
For example, the setup on CentOS is quite easily managed. To verify the login data, you need a special pluggable authentication module (PAM) that communicates with the Vault server and verifies the one-time password (OTP). To field any failures in communication with the Vault server during testing, you need to install a public key as a backup on the machine. Start by adding the SSH back end to your vault:
$ vault mount ssh
You can pick up the vault-ssh-helper
PAM from the Git repository [3]. After installing on the target server, you need to verify the PAM configuration for the SSH daemon and sshd_config
to ensure that SSH actually uses PAM for logins. Following the documentation on GitHub [3], you verify the configuration using the following command:
$ vault-ssh-helper -verify-only -config=/etc/vault-ssh-helper.d/config.hcl
For the login to work, you need to configure access to the vault. This is achieved with the following command
$ vault write ssh/roles/ec2instance key_type=otp default_user=ec2-user > cidr_list=w.x.y.z/32
which sets the key type to otp
and the user to the default ec2-user
. You can randomly adapt the ec2instance
role name. The use of the key is restricted to the machines listed in cidr_list
(or the appropriate subnet): If the server generates an OTP, test it with the next command. It should be noted that the SSH back end generates the OTP and then writes it to the protected storage (Figure 4), which is why the command starts with vault write
. Now write
the credentials for the previously selected role name:
$ vault write ssh/creds/ec2instance ip=w.x.y.z
Despite successful tests on both sides, it can happen that a login is not possible if SELinux is activated and enforced. If this is the case, you might need to modify the rights for access to the network for the SSH login process. First, however, try the login from your client machine with the command:
$ vault ssh -role ec2instance ec2-user@w.x.y.z
The OTP is now in the first line of the output. Verify the SSH fingerprint and enter the password. For further automation, you can install the sshpass
program. However, manual verification of the SSH fingerprint no longer works. If the login fails, check the log data in the /var/log/audit/audit.log
file on the server for a similar entry:
[Error]: Put https://vault.example.com:8200/v1/ssh/verify: dial tcp w.x.y.z:8200; connect: permission denied
If this exists, you can customize the SELinux configuration straightaway with the use of these entries:
$ grep 'avc' /var/log/audit/audit.log | audit2allow -R -M vault.allow $ semodule -i vault.allow.pp
Now the login should be successful. Next, create a policy for accessing the various SSH logins. You can, of course, use SSH to log in to servers in a cloud environment. In case of staff changes, you can simply revoke the token or update the GitHub team. Auditing in Vault lets you trace user logins with shared SSH user accounts.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)