Secrets management refers to the tools and methods for managing digital authentication credentials (secrets), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts, and other sensitive parts of the IT ecosystem.
While secrets management is applicable across an entire enterprise, the terms secrets and secrets management are referred to more commonly in IT about DevOps environments, tools, and processes.
“Three may keep a secret, if two of them are dead.”
― Benjamin Franklin, Poor Richard's Almanack
Managing and sharing secrets is a complicated task. There are various environments, with many services, where each needs to authenticate itself.
If you're working in the Operations team, you clearly faced a secret committed to a git repository at one point. Even if the repository is private, this is a big no-no. If someone accidentally changes the repository to be public, or push a file with secrets to a public repository, there's no turning back. The secret will be out there in the wild.
Before I proceed, I want to ask you few questions:
Where does your organization keep its sensitive data? Is it in an encrypted file? A database? A shared tool such as 1Password?
Who can access it?
How easy is it to add a new secret, or update an existing one?
Do you manage your secrets or they manage you?
Hashicorp Vault
Hashicorp Vault is an open-source robust secret management. It serves as a secret repository with access control lists, auditing, and TTL access to the secrets. It also supports a variety of authentication mechanisms and storage backends.
Vault keeps your secrets encrypted on disk and on transit. It has a simple API to communicate with and great documentation. The website presents two main use-cases:
Secrets Management: centrally store, access, and distribute dynamic secrets such as tokens, passwords, certificates, encryption keys.
Data Protection: keep application data secure with centralized key management and simple APIs for data encryption.
It gives you a central place to safely store secrets. Define who can access what, with an audit on the operations. Use short-lived tokens to reduce the impact in case of secrets gets exposed. Has great APIs you can leverage to automate processes.
Vault takes their business field seriously. Its architecture is a little complex, so let's quickly overview the components and explain them in simple terms.
Secrets Paths
Inside Vault, secrets kept on a file-system like path. Every secret is structured as a JSON object, with key-value pairs. These files are versioned and keep their history (refer to KV secrets engine)
Policies
Vault uses policies to define fine-grained access-control. A policy is made of a list of paths (with regex support). A policy is then attached to the token and determines what secrets a token can access and what actions it can perform (create, read, update, delete).
Authentication and authorization
We use the term authentication to refer to the first phase of the login process. For example, the user provides the correct username and password to authenticate. If the credentials match, the user is authenticated.
The authorization part comes next. It defines what an authenticated user has access to.
To perform operations on the Vault, a user needs to authenticate first.
Vault refers to this as authentication backends.
It is a list of authentication methods a user can use to authenticate.
The simplest option is a token, where you perform the login operation using a pre-defined token to gain access. This is a bad idea. There are better options.
Vault has SSO (OIDC) integration. People in the organization can access using their AzureAD or Google accounts. Once you set it up, everyone that has an account can access Vault! You don't need to manage credentials for every person individually.
Once the user logs in, the policies applied to his account or groups in the organization are applied to his token. This defines what he can do inside Vault.
The Flow
Except for token-based authentication, all other methods work the same way. You first provide your credentials (username/password, SSO, etc.) to perform a login action. In exchange, Vault returns a temporary token for you to use in subsequent API calls. The temporary token is defined by its attributes - lifetime, is it renewable, etc.
When using the UI or the CLI, these things happen behind the scene. Yet, if you're using the HTTP API, you'll need to perform login action and grab the token returned by Vault.
This is a new era. Developers can now read and add secrets by themselves and share these with Operations seamlessly. This increases the velocity of both teams and improving the security as a side-effect. For example, when an employee leaves the company, his access is revoked easily. Or the usage of short lived tokens instead of static passwords.
CI/CD pipelines
The deployment platform should also access Vault. During the build and deployment processes, the platform can get the secrets using the approle authentication method. The approle method gives you the option to configure applications access type. This type should have a short time-to-live so it's useless after the deployment process.
We can take it a step further. Now that we have a centralized secrets store with an API, we can build a Jenkins job that generates secrets and push them to the Vault. This formalizes the procedure and prevents humble human mistakes, such as weak passwords.
Increase teams productivity
As the developers' team grows, without an appropriate tool time is going to be wasted here. Nobody likes to wait to test something just because they don't have the password yet. How much time is spent here? This can be solved by.. using the right tool for the job.
Having an interface to read and add secrets would remove the toil of secrets maintenance.
Summary
Using a secrets management tool has numerous benefits, but I presume most of them are unseen. On the surface, it eases the process of adding or updating a secret and managing a unified access to them, by both Dev and Ops. Replacing a secret becomes an easy task for Operations.
It provides all this while keeping high-security standards and auditing. It presents an API to automate the daunting toil of managing them yourself using a less sophisticated mechanism such as files or a database.
It takes your secrets to the next level, and I haven't touched the more advanced capabilities this tool has (dynamic secrets and AWS authentication method, for example). If you are intrigued, go check the documentation.
The new capabilities introduced to automate processes shouldn't be considered lightly.
How do you manage your secrets?
Oldest comments (0)