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.

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.

Figure 3: The process of an SSH login with Vault with, in this example, an OTP.

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

Figure 4: SSH logins are handled by the OTP generated here.

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.