Hi
After using Vault on a dedicated VM since 2 years, it’s now time to re-think the architecture due to the evolution of needs and practices, so I got some questions relative to Vault 
Question 1 - For us, using Docker is easier for Vault deployment,configuration and above all, update. However, Docker isn’t the most secure system as it shares kernel and VM’s storage. So, is it fair to use Docker and strenghten it or is it more advised for security purpose to stay on VM ?
Question 2 - We’re focused on HA but our Vault activity is only related to dozens of GitLab (using JWT auth)/Ansible jobs (using AppRole auth) to retrieve secrets. Does create a Vault cluster (2 VMs or a K8s cluster if we go to container) is easy to handle and to update ? or is it reserved to very large secret management ?
Question 3 - When we start our Vault journey, we used to enable kv secret engine then create every secrets we need into it, then we restrict access with policies and AppRole. By reading some Vault documentation and some web articles, it seems that a trend is to enable secret engine mutliple time (like kv for SRE, kv for DEV, kv for SysOps and so on…). From a management perspective, which one is advised ? one KV where “everything” is put into or different KVs depends on the team/application needs ?
Thanks a lot for your advices !
Gael
Hi @motorbass,
RE 1: We have many customers who run Vault in a containerized, sensitive environment so whether you run as a container or VM, you are as safe as your environment.
On whether you should run as a container or VM, I would back up and define how critical Vault is to your environment. Is Vault a tier 0 app? Meaning do one or more critical pieces of your environment depend on Vault? If yes, I would run in on a platform that you/your teams are best suited to support. If your team lacks in-depth Kubernetes skills (I say Kubernetes because of a later question, but this could be any container orchestration system), then I would probably not (yet) run Vault there and focus on running it in a platform that is supported by your teams skill set. No wrong answer here, just depends on your environment and team make up.
RE 2: Similar to 1, this depends on your teams skill set. Managing Vault (or any self-managed app for that matter) does require you to spend time ensuring your teams have the skills and time to support it. If you are a Vault expert, but you’re spread out supporting multiple apps, will you have time to test upgrade, failover, failback, DR processes? If not, maybe look into managed Vault offerings like HCP Vault so you can focus on consumption of Vault, rather than management of Vault. Like 1, no wrong answer, just depends on what you have time to manage.
RE 3: Guess what my response will be… It depends! Again, no wrong answer here. Does your org have any regulatory/compliance requirements? Some may require separation of duties, and a single KV mount might not satisfy an auditor, even if you can show policies manage access to each secret. Separate KV mounts give you a bit more separation, but still requires proper policy management to ensure wildcards aren’t inadvertantly giving access to a mount that it shouldn’t. Separate mounts might also open the door for your to hand off management of the secrets engine to different teams, allowing them to create/manage secrets on their own instead of centralizing that but… it depends!
I hope that at least gives some clarity/tips for you to think of. You know your environment better than anyone, and youre asking the right questions, but you also have the right answers.
Hi @jonathanfrappier thanks a lot for the answer even if I know “i have the right answers” I was asking all of that just to got some feedback depends on usage.
You ask the right question about if “Vault is a tier 0 app” , it leads the whole “answer”. Same way for Vault consumption vs Vault amangement
Anyway, those question and thoughts help me to focus on the right strategy to have, thanks again
1 Like