We are very excited to bring Secret Manager to the market. Let us know if you have any questions!
I wonder how is GCP Secrets Manager comparing to Hashicorp Vault? Is GCP SM implemented in Hashicorp Vault (or Berglas) behind the scene? If not, what are the differences in terms of feature set?
Vault works great on GCP, and it's used by hundreds of enterprises who want brokered identity management across clouds, dynamic secrets, and an open core model that fits their business.
However, we kept hearing that sometimes Vault was complex for some small problems. If you're not using its advanced functionality, Vault is incredibly cost prohibitive. It doesn't run well in a serverless environment, so you have to pay for VMs 24/7 even when secrets aren't being accessed.
We continue to contribute to Vault and build deeper Vault integrations into GCP - that's not changing. Secret Manager provides choice. Just like there's certain scenarios where you'd prefer a NoSQL database over a relational one, there are scenarios where you'd prefer Secret Manager over Vault and vice versa.
Since this question and "Secret Manager vs Cloud KMS" keep coming up as questions, I'm going to work with our team to put together something in the documentation.
AWS: $0.40 per secret per month.
GCP: $0.06 per active secret version per regional replica per month.
i don't understand the GCP pricing correctly. Can someone shine a light here ...
The secret version contains that actual secret data (i.e. "ABCD1234"), and you can choose the regions in which you want that secret data replicated. Each region you choose is $0.06.
So if you had 1 secret with 12 versions stored in 2 regions, that would be 12 x 2 x $0.06/mo = $1.44. Hope that helps!
EDIT: replaced "*" with "x" in math because it was getting parsed as italics
This is hopefully simpler to use and easier to audit.
i especially like exemptions; the ability to _not_ log for specific service accounts/identities is very handy.
Does this look appealing?
The benefit of AWS Secrets Manager has been that it integrates directly with other services. In ECS/Fargate, you can create a task definition and list secrets to be injected at run time. It also has features like secret rotation so you don't have to roll your own (well, you kinda do w/Lambda, but they have samples), and you can use things like IAM to lock down access per-secret or per-IAM-ARN-hierarchy.
Like everything in AWS, it'll cost you more, but it'll also eliminate a lot of engineering time. If you're trying to pinch pennies, use Vault or something hokey like pulling a token from AWS SSM PS or S3 and rely on IAM roles/profiles/etc for access control.
There is nothing stopping you from forking the project and adding all the enterprise functionality you want.
"The primary orchestrator going forward is Kubernetes. Mirantis is committed to providing an excellent experience to all Docker Enterprise platform customers and currently expects to support Swarm for at least two years, depending on customer input into the roadmap. Mirantis is also evaluating options for making the transition to Kubernetes easier for Swarm users."
Also, I haven’t needed to integrate something like Vault because the Swarm secrets feature covers my use case perfectly.
I currently have my secrets stored in an encrypted text file in case I need to bring them back up.
For example, with Postgres it can store root creds and issue non-root, time-bound creds for each service. Vault's "backends" allow it to do _a lot_ of things that a secure static credentials manager can't.
Not to say that this isn't good though – any proper secret management system is better than none :D
Kerberos solves very same problem of using only short lived tokens on the wire when accessing services, but it fall out of fashion .
> Playing with Secrets Manager it looks like anyone with access to the project can access all secrets.
just FYI, this is not the case. the "Secret Manager Secret Accessor" role must be applied per-secret for any identity to read the content of that secret.
You can use KMS as part of your own secret manager, but you would have to store the actual secrets somewhere else, like GCS or Datastore. KMS stores encryption keys, and has an API for encrypting/decrypting. For example to retrieve a secret using KMS you would get the encrypted data from where it is stored, like Datastore, and send it to KMS to have KMS decrypt the data. Secret Manager actually stores the secret, so a single API call can retrieve the decrypted value. Secret Manager also has versioning, which is important when rotating secrets. If you were building your own solution around KMS you would need to do versioning in your storage schema, wherever you end up storing the secrets.
For example, this might be something like “store a secret ‘my app remote API key’ encrypted with a regularly rotated key and allow ‘my app container’ to retrieve the value”.