Live data from Hacker News

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

aws.amazon.com

131–137 of 137 posts

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

#131

Earlier quoted context omitted.

You seem to be thinking of a detected compromise, which may have compromised secret X, and your response is to change secret X right now. And I think that's the correct response. But in another sense, all your secrets are potentially compromised, all the time. That is, there are compromises that you don't detect, or don't detect right away. They happen. What should you do? Well, you change the secrets every 90 days,…

If you're talking about secrets used by users (which isn't what AWS Secrets Manager is used for), that is specifically covered by NIST 800-63B [1] which recommends: * Do not impose other composition rules (e.g. mixtures of different character types) on memorized secrets. * Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator comp…

> The energy would be better spent eliminating potential for unknown, undetected attacks.

Think both/and, not either/or. Yes, work on eliminating unknown, undetected attacks. But you're never going to be perfect at it, so also work on minimizing the damage from undetected attacks. If you're not dealing with human-remembered secrets, sure, go down to rotating every few seconds. By doing so, you make the compromise harder to exploit. Even though you don't make it impossible to exploit, "harder" is still worth doing.

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

#132
post #17

Earlier quoted context omitted.

It'd be cheaper than running Vault with a backing Consul cluster which also provides rotation and other features. There is a point where Vault is more cost effective, but I believe it'd require a ton of requests and secrets to justify min 6 machines of at least t2.micro that also need to managed and secured.

...and that's without a FIPS 140-2 Level 3 backend for a HSM as well, right? (Secrets Manger has that I assume). With Vault 1) you have to get Hashi Enterprise 2) Pay for a very pricey HSM.

No, I believe they just use KMS or GCM either which is backed by an HSM and it's recommended in their documentation.

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

#133
post #109
post #100

Earlier quoted context omitted.

Brazil + Apollo + Pipelines. I left (and later boomeranged) and was surprised that the outside world hadn't solved these problems nearly as well. Don't get me wrong, Brazil and Apollo probably are ready for a rethink and rewrite, but they do a great job.

What would you change about them?

Hard to say (especially in as public forum like this).

Brazil's dependency model is, I think, very much worth rethinking. Just try to use it for NodeJS. Apollo is fine but slow and dated and needs love. Pipelines works for specific software models and not others (ever seen a pipeline with 500 envs?). Great design for building custom approval steps though (long ago I wrote a now-popular one).

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

#134
post #73

Earlier quoted context omitted.

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.

This sort of model also fits nicely with the AWS ecosystem. EC2 instances (virtual machines) can be given an IAM Role when they boot-up. An IAM Role is essentially an automatically generated access key which is unique to that EC2 instance, and has pre-determined permissions. So in other words – a unique key is generated every time a virtual machine is created. It's fully automated, never shared between instances, and…

I see. So there actually is a bit of magic involved.

I exist, therefore I can.

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

#135
post #130

I am curious as to how it handles those race conditions where a connection is made with the older credentials just after the time the rds master key rotates, or a connection is made with the newer credentials just before the time the rds client key rotates. Short of using two credentials accounts ...

there’s a pretty nifty 4 stage rotation mechanism that solves most, but not all, of those race conditions. More info on it in the post and the docs.

Are we talking about these? createSecret setSecret testSecret finishSecret

These were mentioned around the custom rotation strategy, any pointers to docs describing how it is done if the secret is an RDS Secret?

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

#136
post #64

Does the Secret Rotation for the RDS-integrated credential store actually update the password for the user in the SQL database? If so, thats pretty damn cool.

Oh, I misread it as a secret for Twitter (which, I guess, makes no sense, because tweets are generally public).. and I was wondering how the password got updated on the Twitter side. So I guess, naturally, secrets can only be rotated for AWS services that support it.

You can write the custom lambdas to rotate 3rd party creds.

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

#137
post #134

Earlier quoted context omitted.

This sort of model also fits nicely with the AWS ecosystem. EC2 instances (virtual machines) can be given an IAM Role when they boot-up. An IAM Role is essentially an automatically generated access key which is unique to that EC2 instance, and has pre-determined permissions. So in other words – a unique key is generated every time a virtual machine is created. It's fully automated, never shared between instances, and…

I see. So there actually is a bit of magic involved. I exist, therefore I can.

Yep - they have similar functionality for task roles (aka docker containers on ECS) and Lambdas as well.
Post reply on HN