AWS Secrets Manager Alternative Without Limits: Vault From HashiCorp

Background

Secret management is not an easy topic. Many different approaches, tools or ways of sharing might cause a headache. In the IT world, you shall secure what matters to your business, database passwords, credentials or just email address and password to a 3rd part service.

Many modern tools with a plugin for web browsers might not meet all requirements, for instance, advanced policy systems. When a remote job is becoming more popular or your team grows fast — it looks like a perfect place for Vault from HashiCorp. In comparison to different secret stores (eg. LastPass, 1Password, AWS Secrets Manager), Vault has become a top-quality product for any cloud or automation process to share non-trivial data (service accounts, time-based passwords, TLS certificates), where the others are good enough for simplest data or just personal usage.

Vault is an open-source tool aiming to solve the problem of managing secrets (API keys, credentials for 3rd part services). It can be easily integrated with the most popular programming languages by using programming libraries delivered by HashiCorp or the community. Sharing data is sensitive and located at the crossroads of 3 areas of responsibility: security, operations, and developers — thanks to Vault you could easily increase data safety and put it on a higher level.

Vault itself stores all information encrypted with 256AES on GCM, it should give you enough confidence that your data is safe and can be only decrypted based on keys known only to Vault.

Vault uses tokens to proceed with an action assigned to an account based on policies. Each token can be created, revoked or expired eg. you can generate a token that will expire in a given time.

How to use it?

Vault has 3 (three) kind of interfaces for end-users:

• CLI (a terminal executable application)
• JSON API
• User Interface through a web browser — it’s pretty useful especially for people who do not work through a terminal or just do not code.

Single source of secrets

Vault is not only a secret manager, but it can also manage password rotation on the Active Directory, generate PKI certificates, integrate well with other HashiCorp tools like Terraform, Nomad or Consul. There is also a wide toolset for other DevOps tools like Ansible, Kubernetes, docker-compose or various CICD.

GitHub Teams

Our company uses GitHub as an organization — it helps to organize people in teams. All permissions for GitHub repositories and projects are based on teams. The GitHub’s team features simplify managing people — it’s much easier to give indirect access to a repository, by managing just a team.

Vault allows using GitHub as an authentication and authorization method based on a GitHub personal access token. This method of authentication is useful for people like developers, project managers, office managers or even non-IT teams.

GitHub Auth method

Auth methods must be configured in advance on Vault’s end, however, it requires just two following steps:

• enabled the GitHub auth method
• set an organization name for the auth method

After that, all users from the organization will have access to Vault. In general, it gives the possibility to manage Vault’s users based on people from the Organization.

Policies

Policies provide a declarative way to grant or forbid access to certain resources and operations in Vault.

path "panthers-store/*" { 
  capabilities = ["create", "read", "update", "delete", "list"]
}

In the sample policy we might notice given parts:

NOTE #1 there is also deny capability, which disallows access - this always takes precedence regardless of any other defined capabilities including sudo

NOTE #2 all capabilities could be found here.

Let say that we name the policy panthers-policy and any other grants or forbids (for different paths) would be stored inside the policy. To sum up - one team must have one policy.

NOTE #3 One team must have one policy is just our internal solution to keep files and policies well organized. Vault itself allows assigning as many policies to a team as needed.

For instance:

path "panthers-store/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
path "panthers-codes/*" { 
  capabilities = ["read", "list"]
}

The next step is to create a direct mapping between the team on GitHub and the policy. It could be done easily through CLI or a terminal emulator on the User Interface.

vault write auth/github/map/teams/team-panthers value=panthers-policy

Team names between GitHub and Vault have to “slugified” as Vault’s paths can not include capitalized letters or any other special or white characters. In our case team on GitHub has the name Team Panthers and the equivalent name on Vault's end is team-panthers.

Vault also gives us the possibility to assign a policy directly to a user from the organization, but not from the team. From some reasons, we do not want to add `Joe Doe` to the team, but at the same time, we want to give him access to those secret stores, eg:

vault write auth/github/map/users/joe-doe value=panthers-policy

Summary and conclusion

This kind of approach should allow you to have full control over sharing secret data across teams and members managed through GitHub.

In comparison to AWS Secret Manager, AWS Parameter Store or Google Secret Manager, Vault stays somewhere in between cloud, applications, and developers. By being independent of a cloud provider, Vault could be treated as “Encryption as a Service”. Vault itself can be used to dynamically generate AWS IAM users, Google Cloud service accounts what is not possible with secret managers delivered by cloud providers.

Database password rotation or Certificate Authority enforce a service or an end-user to repeat the auth process after a given period time or just redo a set of commands or scripts — with Vault we get the value out of the box — we can get a service account which will expire in 5 minutes. The service account would be renewed when a user successfully passes the auth process and has the right policies to renew/create a secret account (both things are done on Vault end). Please remember that Vault is also a great alternative for one-time-read secret services like QuickForget.com — you will not have to share a link through Slack (and with the link preview feature, we can be 100% sure that the secret would be read once somewhere in the Slack infrastructure) — just share it through Vault by passing a wrapping token.

If you would like to use Vault with GitHub inside your organization, hosted on AWS or Google Cloud feel free to contact us!

Originally published at https://selleo.com.