leon/blog
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Finish vault agents post
All checks were successful
Build Docker Image / docker (push) Successful in 26s
Details

Browse Source
This commit is contained in:
Lol3rrr
2026-09-27 16:21:29 +02:00
parent 5ba2769037
commit f659eb3c81
1 changed files with 17 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
content/vault-agents/index.md
View File

@@ -1,8 +1,7 @@
+++ +++
title = "Vault Agents" title = "Vault Agents"
date = 2026-09-27 date = 2026-09-27
description = "Setting up vault-agents for my servers" description = "Setting up vault-agents on my servers"
draft = true
[taxonomies] [taxonomies]
categories = ["Homelab"] categories = ["Homelab"]
@@ -12,19 +11,24 @@ tags = ["Homelab", "Vault"]
toc = true toc = true
+++ +++
My journey to setting up vault-agents on my servers to handle dynamic secrets in configurations. This is my experience of setting up vault-agents on my servers to handle dynamic secrets in the configurations of my services.
<!-- more --> <!-- more -->
# Configuring the Vault Server # What is vault-agent?
We need to configure the vault server, such that we can generate the tokens for our agents and assign them the appropriate policies. Vault-agent[^vault_agent] is a kind of companion tool for vault[^vault], which allows one to start integrating vault and its capabilties into existing systems or systems that cannot easily be changed to integrate vault natively.
For my use-case, the most important feature is the option to fetch secrets from vault and use it to template out files, specifically configuration files.
This makes it a lot easier to manage secrets that need to be available locally at program startup, without having to update it manually everytime it changes or exipres.
For this purpose we first create a kind of account for each of the servers, that a vault agent will be installed on. # Configuring the Vault Server
First we need to configure the vault server, such that we can generate the tokens for our agents and assign them the appropriate policies.
For this purpose, I first create a kind of account for each of the servers, that a vault agent will be installed on.
In vault this translates to an identity and an alias for each of the servers. In vault this translates to an identity and an alias for each of the servers.
All of these identities are then grouped into a vault-agent group, which will actually have the shared policies assigned to it, such that there is only one place to manage all of the shared access, while also retaining the option to assign policies to individual servers, for example if one of them required extra credentials as it fulfills a unique job not shared by other servers. All of these identities are then grouped into a vault-agent group, which will actually have the shared policies assigned to it, such that there is only one place to manage all of the shared access, while also retaining the option to assign policies to individual servers, for example if one of them required extra credentials as it fulfills a unique job not shared by other servers.
To then allow the vault agents to actually authenticate with vault, I decided to simply use tokens directly instead of generating credentials using something like AppRole, but I still do not love this approach yet. To then allow the vault agents to actually authenticate with vault, I decided to simply use tokens directly instead of generating credentials using something like AppRole, but I still do not love this approach yet.
For this I created a backend role for the token auth mechanism in vault, which only allows the previously configured aliases to authenticate against it (as well as allowing orphaned tokens and renewing). For this I created a backend role in the token auth mechanism, which only allows the previously configured aliases to authenticate against it (as well as allowing orphaned tokens and renewing).
This means I can now generate a unique vault token for each of my servers and they can use it to authenticate as that server against vault to load any secrets they might need. This means I can now generate a unique vault token for each of my servers and they can use it to authenticate as that server against vault to load any secrets they might need.
@@ -37,10 +41,10 @@ Deploying the vault agents to my servers now comes down to:
# Deploying templated Configs # Deploying templated Configs
Now that vault-agents are running on my servers, it is time to actually use them for something useful. Now that vault-agents are running on my servers, it is time to actually use them for something useful.
This means I need to make it easy to integrate the deployment of templated configurations for other services, which I decided to do by introducing a simple ansible-role. This means I need to make it easy to integrate the deployment of templated configurations for other services, which I decided to do by introducing a simple ansible-role.
This role takes care of creating the correct configuration for the vault-agent to template out a file and placing it in a shared space, where the vault-agent can pick it up. This role takes care of creating the correct configuration for the vault-agent to template out a file and placing it in a predefined location, where the vault-agent can pick it up.
It will then also trigger the vault-agent on the server to restart / reload its configuration to pick up the newly created config and start outputting the templated configuration. It will then also trigger the vault-agent on the server to restart / reload its configuration to pick up the newly created config and start outputting the templated configuration.
So all I need to do for using templated configurations for a service that I want to deploy, is give the vault agent user the permissions to write my config to where my service expects it, give it the template to use and providing a command to execute whenever the written out file changes, in case the service does not automatically detect changes to it. So all I need to do, to deploy a service using templated configurations, is give the vault agent user the permissions to write the config to where my service expects it, give it the template to use and providing a command to execute whenever the written out file changes, in case the service does not automatically detect changes to it.
# Example Uses # Example Uses
## Nomad - mTLS ## Nomad - mTLS
@@ -51,7 +55,7 @@ However now with the vault-agents, I can configure them to automatically fetch t
This workflow is a lot easier to maintain, as there is no human involvement to rotate the leaf-certificates, and allows for enforcing best practices, like short lifetimes for the leaf-certificates. This workflow is a lot easier to maintain, as there is no human involvement to rotate the leaf-certificates, and allows for enforcing best practices, like short lifetimes for the leaf-certificates.
## Nomad - Consul ACLs ## Nomad - Consul ACLs
My nomad cluster is very tightly integrated into consul, to make use of its service-mesh capabilties and some other smaller features. My nomad cluster is very tightly integrated into consul, to make use of its service-mesh capabilties and some other features.
However because I have ACLs enabled on the consul cluster, every nomad client requires an ACL token to connect to consul. However because I have ACLs enabled on the consul cluster, every nomad client requires an ACL token to connect to consul.
Managing this manually would either mean a lot of maintenance for me or using tokens with very long lifetimes, which are both not good options. Managing this manually would either mean a lot of maintenance for me or using tokens with very long lifetimes, which are both not good options.
@@ -66,10 +70,12 @@ However because I use a vault token, which expires after at most one day with my
This is not a huge issue for me in this case, but mostly annoying as I need to keep that in mind during maintenance and adds another kind of weird thing. This is not a huge issue for me in this case, but mostly annoying as I need to keep that in mind during maintenance and adds another kind of weird thing.
## One bad config infects the entire agent ## One bad config infects the entire agent
Currently if I accidentally deploy one bad vault-agent config, for example by writing a custom config for templating a config, then the entire vault-agent on the server is not working properly and thus affects other services as well. If I accidentally deploy one bad vault-agent config, for example by writing a custom config for templating a config, then the entire vault-agent on the server is not working properly and thus affects other services as well.
I have no good approach to prevent this, besides enforcing the use of the ansible-role, which could be updated to make sure that after every change the agent is still running without issues, but that is not yet implemented. I have no good approach to prevent this, besides enforcing the use of the ansible-role, which could be updated to make sure that after every change the agent is still running without issues, but that is not yet implemented.
# References # References
[^vault]: [Vault](https://developer.hashicorp.com/vault/docs/about-vault/what-is-vault)
[^vault_agent]: [Vault Agent](https://developer.hashicorp.com/vault/docs/agent-and-proxy/agent)
[^vault_pki_api]: [Vault PKI API](https://developer.hashicorp.com/vault/api-docs/secret/pki) [^vault_pki_api]: [Vault PKI API](https://developer.hashicorp.com/vault/api-docs/secret/pki)
[^consul_template_secrets]: [Consul Template Secrets](https://github.com/hashicorp/consul-template/blob/main/docs/templating-language.md#secret) [^consul_template_secrets]: [Consul Template Secrets](https://github.com/hashicorp/consul-template/blob/main/docs/templating-language.md#secret)
[^vault_agent_templates]: [Vault Agent Templates](https://developer.hashicorp.com/vault/docs/agent-and-proxy/agent/template) [^vault_agent_templates]: [Vault Agent Templates](https://developer.hashicorp.com/vault/docs/agent-and-proxy/agent/template)