Live data from Hacker News

AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely

aws.amazon.com

71–80 of 137 posts

Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely

#71
post #70

For those of us living in the service-development stone ages, is the idea that a secret-manager service replaces any number of ad-hoc local secret-storage and configuration mechanisms with a single robust mechanism that takes only a single root credential to retrieve all the individual secrets that your service needs? You do still have to figure out a way to securely provide the root credential to your service so tha…

The big missing piece is roles. No service uses a root access key directly. Instead, there's a webserver role with access to a relevant secrets group but no access to data warehouse secrets, for example.

Access keys can be provisioned and downloaded straight onto the box from the service. Sure, a compromise is bad, but only exposes the secrets that would be available on the pwned box regardless.

Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely

#72

First reaction: Holy crap! They finally turned ParameterStore into a proper product! Second reaction: Holy shit that's expensive [for what it does]. ParameterStore is free (minus the KMS component). The only value-add is secret rotation and that's not something that most of the time makes sense to use. [Edit: I'm not advocating for no rotation; see replies] Edit: Had more time to think about it. Someone enlighten me:…

Totally had the same reaction. The first thing I thought of is "wait doesn't ParamStore already do this?"

Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely

#73
post #71
post #70

For those of us living in the service-development stone ages, is the idea that a secret-manager service replaces any number of ad-hoc local secret-storage and configuration mechanisms with a single robust mechanism that takes only a single root credential to retrieve all the individual secrets that your service needs? You do still have to figure out a way to securely provide the root credential to your service so tha…

The big missing piece is roles. No service uses a root access key directly. Instead, there's a webserver role with access to a relevant secrets group but no access to data warehouse secrets, for example. Access keys can be provisioned and downloaded straight onto the box from the service. Sure, a compromise is bad, but only exposes the secrets that would be available on the pwned box regardless.

OK, so "root" wasn't really the right term. I get an X credential so I can be an X, and nobody needs to worry that I also got enough to be any part of a Y. Thanks.

Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely

#74
post #32

Earlier quoted context omitted.

It depends on the secret and the degree to which the secret is exposed. SSH creds should get rotated constantly ; a one-hour SSH login cred is a significant exposure. But an API secret that is kept in Parameter Store and not exposed to developers doesn't really benefit from rotation every 3 months in proportion to the amount of mechanism required to do that.

What are you assuming about exposure? If a SSH key lives on a well-secured workstation or bastion host (and you ideally don't agent-forward it to insecure hosts), rotating that key once per hour doesn't seem a top priority to me? E.g. a sudo password is (lower-impact, but) more likely to get exposed to compromised hosts? ("Well-secured workstation" is arguably an oxymoron, of course...)

Wait, you keep private SSH keys on bastion hosts?

It's much better practice to use the bastion as a proxy to the other hosts. This is easily achieved using the ProxyCommand option of OpenSSH.

No agent forwarding, no secrets kept in random hosts.

Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely

#76

Kinda similar to what Hashicorp's Vault does for secret management but hosted.

There's really no comparison. You could use Vault to build a PKI. You couldn't say the same for a proprietary, vendor locked solution like this.

Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely

#77
post #51

> $0.40/secret/month WOWZER. I get having a managed solution is great, but you don't have to store many secrets before running your own Vault server makes sense.

At my work, we have a vault service, but it takes 3 servers for vault plus another 3 for consul and they are not very cheap servers (m4.larges). Our rough calculations, using a 3x3 vault/consul architecture, estimated you'd need over 1100-1300 secrets to make it worth implementing vault (not including development/maintenance cost which could be significant. and if you have multiple, independent environments, it gets worse.

The real issue for some of the people at my work is the vendor lock-in versus vault.

Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely

#78

How is this different than KMS? “Key Management Service” is practically synonymous with the name of this new product, so how exactly do the two differ/interact?

Well, you can use KMS to do something similar, but without the auto-rotation. 1. Use a KMS key to encrypt a secrets file (obviously, never check this into source control) 2. Store the encrypted secrets file in an S3 bucket 3. Tie a new IAM role with kms:Decrypt and s3:GetObject policies for the relevant resources to your EC2 instance 4. On app start, get the KMS key and secrets file, decrypt, and set environment vari…

This seems like the easiest solution, and we've been pretty successful. We have sub-folders based on your environment and only machines have roles that can read production. We also realized you don't even have to encrypt and decrypt.. just turn on encryption for the S3 bucket, I believe it's the same thing.

Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely

#79
post #51

> $0.40/secret/month WOWZER. I get having a managed solution is great, but you don't have to store many secrets before running your own Vault server makes sense.

At my work, we have a vault service, but it takes 3 servers for vault plus another 3 for consul and they are not very cheap servers (m4.larges). Our rough calculations, using a 3x3 vault/consul architecture, estimated you'd need over 1100-1300 secrets to make it worth implementing vault (not including development/maintenance cost which could be significant. and if you have multiple, independent environments, it gets…

Consul only makes sense if you are already using it for something else. If just Vault, you can use DynamoDB (with full HA) or S3 (without HA support), same with Azure and Google Cloud (although without HA). There are other backends, like PostgreSQL.

Re: AWS Secrets Manager – Store, Distribute, and Rotate Credentials Securely

#80

Earlier quoted context omitted.

At my work, we have a vault service, but it takes 3 servers for vault plus another 3 for consul and they are not very cheap servers (m4.larges). Our rough calculations, using a 3x3 vault/consul architecture, estimated you'd need over 1100-1300 secrets to make it worth implementing vault (not including development/maintenance cost which could be significant. and if you have multiple, independent environments, it gets…

Consul only makes sense if you are already using it for something else. If just Vault, you can use DynamoDB (with full HA) or S3 (without HA support), same with Azure and Google Cloud (although without HA). There are other backends, like PostgreSQL.

[deleted]
Post reply on HN