Kubernetes can, through a CRD, retrieve secrets from AWS Secrets Manager.
Vault cannot replace this functionality, right?
Does anyone know a good comparison of AWS Secrets Manager and HashiCorp Vault, similar to the following?
We don’t have a formal write-up of the differences between them (though, we probably should), but some quick highlights:
- ASM is AWS only.
- Vault works in any cloud or data center with one common API
- Vault includes many different authentication methods. ASM is largely AWS IAM.
- ASM only does static K/V storage
- Vault has a wide array of secret engines like PKI, Transit, SSH CA and dynamic cloud credentials
- ASM only has database rotation out of the box and has relatively high TTLs
- Vault allows you to create dynamic secrets which can be unique per instance with very low TTLs.
- Any other secrets than RDS require manually creating rotation logic
- ASM at scale will cost as much, if not more than, Vault Enterprise due to per secret and request based pricing.
- Vault Enterprise includes techniques for world-wide replication, multi-tentancy with namespaces and advanced data filtering and ACLs
- The CRD approach is taking an encrypted secret and putting into K8s as a base64 string. You are technically reducing security by doing this. In that essence, we don’t really want Vault to replace that functionality.
- Stay tuned for better, more secure integrations with Vault/K8s coming shortly
2 Likes
EKS doesn’t really handle external secrets (yet?), but i have to assume it will at some point:
As far as having Vault involved instead of something like this, would having a non-aws tool stuck in between AWS IAM and Amazon’s incomplete k8s implementation typically be too much impedence for customers just getting started with secrets management?