u/redaben_

Stuck in Secret-Zero rabbit hole (HashiCorp Vault/OpenBAO)

My company's secret management is a mess so i am trying to set up OpenBAO for secret management.

At first it looked like a good idea, because i thought it would protect from an attacker that would gain shell access to the server (he could not read .env files or /proc/<pid>/environ etc...).

But when i dag a little deeper into it, i don't understand what is it's benefit. Any method to implement auto-unseal turns out not really more secure thant .env files :

  • OpenBAO with auto-unseal via transit : an attacker that gains access to the transit bao can get everything he wants + you have to keep a token in the main bao to login to the transit one, which comes down to .env files security level.
  • OpenBAO with KMS and IAM (Azure, AWS...): an attacker that gains access to the server can query the IP 169\.254.169.254 and access the master keyr.
  • OpenBAO with KMS and static KMS credentials : same problem with .env files.
  • OpenBAO with static key "seal "static" : equivalent to .env files.
  • OpenBAO with HSM : equivalent to .env because any attacker with access to the server + pin can get the key.

Shamir's secret sharing is more secure than these all (depending on where and how each person store's it's share) but it is not suited for CI/CD etc.

What are your thoughts on this ? Is it possible to set up a secret management system with 0 secrets or something that is as secure and production-ready ?

reddit.com
u/redaben_ — 17 hours ago
▲ 10 r/devops

I am stuck in Secret-Zero rabbit hole (Hashicorps Vault/OpenBAO)

My company's secret management is a mess so i am trying to set up OpenBAO for secret management.

At first it looked like a good idea, because i thought it would protect from an attacker that would gain shell access to the server (he could not read .env files or /proc/<pid>/environ etc...).

But when i dag a little deeper into it, i don't understand what is it's benefit. Any method to implement auto-unseal turns out not really more secure thant .env files :

  • OpenBAO with auto-unseal via transit : an attacker that gains access to the transit bao can get everything he wants + you have to keep a token in the main bao to login to the transit one, which comes down to .env files security level.
  • OpenBAO with KMS and IAM (Azure, AWS...): an attacker that gains access to the server can query the IP 169\.254.169.254 and access the master keyr.
  • OpenBAO with KMS and static KMS credentials : same problem with .env files.
  • OpenBAO with static key "seal "static" : equivalent to .env files.
  • OpenBAO with HSM : equivalent to .env because any attacker with access to the server + pin can get the key.

Shamir's secret sharing is more secure than these all (depending on where and how each person store's it's share) but it is not suited for CI/CD etc.

What are your thoughts on this ? Is it possible to set up a secret management system with 0 secrets or something that is as secure and production-ready ?

reddit.com
u/redaben_ — 17 hours ago