HashiCorp Vault Agent Use Cases

[@deepwork9823]

Very well done! Thanks! 😃

[@TeKanAid]

Thanks!

[@deepwork9823]

@@TeKanAid Subscribed! :-)

[@bilelmohamed6383]

thank you, very clear

[@TeKanAid]

You're welcome glad to hear!

[@Ilya-cw7qj]

It's quite weird. When I start manually script you proposed for the vault-agent.service. There are no errors. When I start "systemctl start the vault-agent.service" then the status is "Active: active (running)" But there are errors like: Sep 08 12:25:39 cnode bash[3810]: 2021-09-08T12:25:39.879-0400 [INFO] auth.handler: authenticating Sep 08 12:25:39 cnode bash[3810]: 2021-09-08T12:25:39.879-0400 [ERROR] auth.handler: error getting path or data from method: error="no known role ID" backoff=8.04s" In case when I manually run the script it gets tokens from the vault agent. What am I doing wrong? After "systemctl restart the vault-agent.service" It works. Maybe something wrong with the dependences of vault-agent.service.

[@TeKanAid]

Take a look at this video, I expand more kzbin.info/www/bejne/f4TFpmOOYqeEiJY

[@con-f-use]

I'm not entirely sure what using the wrapped secret-id in this case achieves over using the secret-id directly. In the wrapped case, you get a new secred-id by unwrapping it. The wrapped one is obtained using the restart-secred-id. To me it seems that since the "restart_secret_id" is written to a file and you can get a new wrapped secred-id and unwarp it using this file, you'd just be in the same situation: if that "restart_secret_id" gets compromised, it would just be the same plus an extra as when the direct secret-id was lost. So it's basically still just a file on your client that has to be kept a secret. What am I missing?

[@TeKanAid]

That's a great observation and I answered this on a webinar I had a while ago. See the answer below: A security concern was brought up regarding a user gaining access to the VM where the Vault-agent and the App are running. The concern is that the user could use the restart AppRole to create a wrapped secret-id to then gain access to the App’s secrets. The fact of the matter is that if a user (inside the VM) logs in as root, we have a much bigger problem than trying to secure the Vault-agent. They essentially have access to the app itself and can do whatever they like. In fact, they can simply talk to Vault directly via the Vault-agent as a proxy which effectively uses the AppRole associated with Vault-agent without needing to use the restart AppRole altogether. Or they could get the Vault token used by the Vault-agent from the sink file and authenticate to the Vault server that way. Moreover, if the Vault-agent is also writing secrets to the file system, then the root user can see these secrets directly. Keep in mind that this is all limited to the specific App’s secrets that the Vault-agent is working with as defined in the Vault policy. So the VM hosting both the application and the Vault-agent needs to be secured the same way you would harden any of your servers. Perhaps SELinux or AppArmor could be used to confine the root user, but this is out of the scope of the Vault-agent conversation. Remember: What we’re trying to solve for here is the secure delivery of the role_id and secret_id for the Vault-agent to authenticate into the Vault server via AppRole. We do this by sending the role_id and the wrapped version of the secret_id via 2 separate delivery mechanisms (could be Packer and Jenkins) to the VM hosting the Vault-agent. The reason we send the wrapped version and not the secret_id directly is to protect the secret_id during delivery. However, we run into the Vault-agent restart problem mentioned. So then we can solve that by also sending a restart_role_id and a restart_secret_id also via 2 separate methods.

[@con-f-use]

@@TeKanAid Thank you for taking the time and effort to clarify. In summary, I'd say that the wrapping "extra" step is, in essence, is a means to detect interception. Since the wrapped token is single use and only valid for a limited time, we would see if someone intercepted it, because they'd either have to use it very soon (else it expires or gets used by the app - both rendering it useless) or the app would fail because it can't unwrap the used up id. Using the secret-id directly opens you up to someone duplicating in transit and using it, and you not noticing as easily, because the app would still function as long as it got the intercepted id as well. So if I personally deploy the machine and configure the secret-id manually, I should be fine (provided the machine and my connection to it are secure).

[@TeKanAid]

Yes exactly, our concern is in the delivery process of the secret_id since it usually is delivered via a CI/CD pipeline

[@jeyxi]

Hello. Can you integrate a spring boot application to vault via vault agent? Currently, we are directly retrieving secrets to vault server. We would like to utilize the vault agent and its token lifecycle management. Thanks!

[@TeKanAid]

Take a look at this cloud.spring.io/spring-cloud-vault/reference/html/#vault.config.authentication.vault-agent

[@Ilya-cw7qj]

Hi, Vault agent caching caches secrets only for access to the vault server to mitigate the request pressure for getting auth token. I mean that the agent isn't responsible for storing apps secrets, e.g. DB username, passwords, etc. Am I right?

[@TeKanAid]

Yes the agent caches tokens and leases only. So it won't cache KV secrets but will cache dynamic secrets which is what leases are. So if you are using the dynamic database secrets engine, the username and password will be cached. This is a good article and has a good diagram explaining caching. learn.hashicorp.com/tutorials/vault/agent-caching

[@andersonsoares9957]

Hey, can this be used for Token/Key Rotation? For example: will the placed token in the sink be renewed only or I will get a new token when the token itself get expired/number of uses has ran out? Thanks in advance.

[@TeKanAid]

The Vault Agent takes care of the token renewal for you. The feature is called Auto-Auth. www.vaultproject.io/docs/agent/autoauth

[@andersonsoares9957]

@@TeKanAid Thank you!!

[@Ilya-cw7qj]

I'd like to know whether the vault agent can respond when the vault server is unavailable. I tested on my home lab. Unfortunately, it doesn't work. When I shut down the vault server my application that asks the vault agent is hanging and disconnected after some timeout. Is it possible to configure the vault agent to respond while the vault server is unavailable?

[@TeKanAid]

2 things, your Vault server needs to be highly available, it is a critical component of your infrastructure. You can also set up caching in your Vault agent

[@Ilya-cw7qj]

@@TeKanAid The vault agent caches only tokens not secrets. It was the question of my customer. Actually, I can’t understand the point of the vault agent availability when the vault server is unavailable. In any cases the secrets are stored on the vault server and as you mentioned it needs to be high available.

[@Ilya-cw7qj]

Could you explain, please? The main purpose of the vault agent is to mitigate the load on the vault server from the client-side. But if it needs to access the vault server from the client side every time when we the secret is needed to be obtained via the vault agent. Is it the same thing when the client addresses the vault server directly without the vault agent in terms of load reduction? I don't see a difference due to secrets are not being cached at the current vault agent release and we need to get them from the vault server via the vault agent.

[@TeKanAid]

Ilya, pls send me a note at [e-mail]

[@AbhishekPandey-ud3fe]

Hi, Thank you for sharing the video as it is very useful for me to implement the things using vault agent instead of communicating directly with vault. While running your code with vault address 127.0.0.1:8200 I am getting error while running the vault agent "auth.handler: error getting path or data from method: error="error looking up wrapped secret ID: Error making API request.". Please help in resolving issue as I am not able to get the solution for same.

[@TeKanAid]

Please watch this video that may help kzbin.info/www/bejne/f4TFpmOOYqeEiJY

[@TeKanAid]

▬▬▬▬▬▬ Announcements📢 ▬▬▬▬▬▬▬ 🔥 If you're interested in a step-by-step course to learn the basics of HashiCorp Vault, check this course out: HashiCorp Vault 101 - Certified Vault Associate ► bit.ly/hc-vault101 In this course you will get to: ⭐ Learn everything you need to know about Vault to ace the Vault Associate Exam ⭐ 8+ hours of video content ⭐ Instructor has his camera on making you feel that you're right in the classroom ⭐ Hand-drawn animated diagrams to help you grasp the topics better ⭐ Lots of hands-on labs to learn by doing ⭐ English closed captions that are searchable so you won't miss a word ⭐ Quizzes to help you grasp the material well ⭐ Join our Community