Introduction to Vault
There are hundreds of applications that need access to critical data in order to work properly. Those sensitive data can be : API keys, passwords, certificates, tokens and so much more. Here comes the need of Vault which is basically a centralized tool that manages and stores secrets related to a specific development project.
Vault offers the possibility of verifying and monitoring who is accessing each secret and how, by exposing a detailed log, encrypting and decrypting data, authorizing access based on policies and also providing different authentication methods that can be either intern such as ‘user/password’, ‘token’ and ‘tls’ or external such as ‘LDAP’, ‘Radius’ and ‘Kubernetes’.
The main key features of Vault are : On-demand secrets generation, data encryption and decryption, leasing, renewal and revocation of secrets.
Vault can be accessible via : API, Web Interface and CLI.
Once Vault is started, it is in a sealed state, it doesn’t allow access to its data. We have to provide it with 3 keys so it can pass to a unsealed state. Those keys are provided by default only during installation.
Example of use case
Vault has different types of secret engines which are : Generic, Cloud and Infra.
- Generic secrets are used to store secrets in key values format (it can be usernames and passwords), certificates, ssh keys etc.
- Cloud secrets are used to store secrets related to cloud platforms such as AWS, Azure, etc.
- Infra secrets are related for example to databases, cluster secrets, etc.
Let’s start by creating a basic key value secret engine to store a database server login information.
After clicking on ‘Enable Engine’, a unified branch for the engine appears in which we can create as many sections (secrets) as we want.
Here, we have defined that the target user can only list all the secrets defined under the path ‘secret/*’, however, for the dbserver one, he has read and list capabilities. Note that we need to be careful to the order of policy definition, (which is the same for the ACL case definition) otherwise, the policy won’t be valid.
Generally, policies must be attached to groups, let’s go ahead and create our group for the policy we just defined.
Now that we have defined our group, We have to create our entity, basically, an entity in Vault is the user or the machine that will access and manipulate the data, but before that, we have to define the authentication methods for our user.
Now that we have finished creating our user, we need to define the alias for it, an alias as generally known, is simply a representation of the username here, its utility is that we can define different aliases for the same user in order to authenticate for different resources.
Now, one only thing left is that we need to define the password for our user, Vault user interface does not support this setup, so we will define it via Vault CLI.
Introduction to Vault integration plugin
Example of use case
To use the plugin first of all we need to download and install the plugin package from the repository using the command:
- rudder package install-file <path to the rpkg>
Or if we have an active subscription:
- rudder package install rudder-plugin-vault
Once the package is downloaded and installed on the Rudder server, we need to define the configuration that basically is the Vault server IP address and the authentication method. Authentication methods supported by the plugin are userpass and token.
In our case, our user is defined with userpass authentication method, we have to configure its credentials in the /var/rudder/plugin-resources/vault.json file on each agent.
While using the plugin, we define the Vault server IP address and authentication mode on each agent, this is a best practice so Rudder Server won’t need to access Vault Server as the agent will take care of the whole authentication and fetching secrets process.
Now let’s create the technique on the rudder user interface that will contain our generic method as follows.
Obviously, this method allowed us to fetch a secret from Vault Server, now let’s suppose for example, that we want to store that secret (that contains the login information of a database server) into a credentials file in our node.
To do so, we can simply create another generic method in the same technique called ‘File lines present’ and we have to indicate the file name and the lines we want to insert into the file.
Conclusion
Both examples we have introduced, showed a basic use case of Vault secret management
and a use case of how to fetch a secret from Vault Server using Vault integration plugin.
To go further with Vault usage, you can check out the Vault official documentation: https://www.vaultproject.io/docs/
Download the Vault plugin from the plugins page and follow this article to start using it on your Rudder server.