Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
How to manage any kind of secret with AWS Secrets Manager (sanderknape.com)
96 points by SanderKnape on July 7, 2018 | hide | past | favorite | 36 comments


This write-up is solid - but man, this product looks questionable. 40 cents per secret per month? With Credstash[0] or a moral equivalent[1] you pay a buck for a KMS key and microcents for the data storage.

RDS rotation is...fine, I guess, if you have an auditor who really wants that and can't write a scheduled job for the task (I've been using one with credstash so long it's just an automatic part of a new environment), but it's got me skeptical.

Something AWS could do, and I'd be very interested in, is a hosted moral equivalent to Vault. Give me a daemon or something to run on an instance, allow me to IAM-gate temporary SSH credentials (and chuck it in CloudTrail) and temporary SQL databases, and that I'd pay for 'cause I really don't want to deal with Vault or HashiCorp. But AWS Secrets Manager, by itself, doesn't really present a good reason-for-being to me.

[0] - https://github.com/fugue/credstash

[1] - https://github.com/codahale/sneaker


No enterprise is going to care about that price. If an enterprise is willing to delegate secret management to an external service in the first place, part of the reason they're doing it is so that they don't have to manage it themselves internally, along with the staffing and related compliance issues, which would cost orders of magnitude more.


It’s replacing enterprise products that cost way more to meet compliance requirements. It would have saved me about $50k on a project awhile back.

No open source product will meet the requirement, because you often need FIPS validated crypto.


> No open source product will meet the requirement, because you often need FIPS validated crypto.

What do you mean? Redhat has FIPS mode. Openssl has FIPS object module. You can create a secrets storage product out of those blocks. Do you mean some specific requirements for the project you were working on?


Rolling your own is expensive if you’re getting audited for compliance that includes FIPS or other things.

You need to have a Dev who understands and documents everything, your ops guys need to be careful to not fix a security bug in OpenSSL that leaves you with a non-validated version, etc.

Or you can give AWS $5/secret/year. It’s the path of least resistance.


I agree it's simple to use aws in this case. I meant specifically the claim that "No open source product will meet the requirement". It may not be the financially optimal solution, but that's not "open source" specific.


I see your POV, but I think the distinction is that RHEL or OpenSSL aren’t vaults. They are components or tools. If RHEL includes a vault product, that would be different.

If I need to sit, I need a chair can support my weight. A box containing 2x4s, a hammer and box of nails doesn’t meet the need.

I’m not disparaging OSS — it just isn’t a good fit for use cases like this when you need to deal with bullshit like FIPS 140-2.


Credstash uses KMS (in much the same way as AWS Secret Provider does) and AES-256 (which is a FIPS 140-2 validated algorithm) internally. If AWS's crypto validates, Credstash's will.


I do not see the value proposition of the RDS rotation feature. RDS supports IAM auth, which gives you a token that is valid for 15 minutes, no need to worry about rotating passwords anymore: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Using...


There are several key restrictions on IAM token auth, not to mention that it may not be feasible to integrate in a given framework. It definitely solves the problem for manual access, but automated access may be a different story.

That said, there are a handful of examples available to handle RDS secret rotation through parameter store with Lambdas and custom cloudformation resources.


Let's say you write a scheduled job - the auditor is going to ask who gets notified when it fails, how you know they will respond to the notification, etc. Much simpler to just rely on AWS to do it for you.


AWS’s secret manager seems like overkill for most projects and it’s expensive - 40 cents per secret per month. The Parameter Store is free and much better integrated with AWS’s other offerings. It also supports encrypted values.


(I do work for AWS)

I was confused by the naming convention at launch, but a secret is a set of key value pairs and not a single key value pair.


I’m looking at the Boto3 docs. It looks like a “secret” is a single key where the value can be JSON text that is a key value pair. Parameter Store let’s you use do a simple key value pair. Am I missing something?


Who says the value needs to represent a scalar value? Why not encode an encrypted JSON string as the value.


It kind of defeats the purpose if you are sharing common setting across services, if you only need one value shared.


Ouch, that is very expensive indeed. Normally AWS has decent prices but this seems way too much per secret.


I imagine parameter store keeps values non-encrypted while secret manager values end up encrypted by a HSM, without the cost of cloudHSM.


One of the options when you are adding a parameter is “securestring”. It uses AWS KMS to encrypt your parameter.

https://docs.aws.amazon.com/kms/latest/developerguide/servic...


Have you looked at what hashicorp charges for vault? It's like $150k per cluster.


Vault is free and open source. Only the “Enterprise” version cost money. I’ve used the open source versions of Consul, Nomad, and Vault before for on prem implementation.


> Only the “Enterprise” version cost money.

Which is what we are comparing here. Enterprise with enterprise. Features equivalency.


What does the Enterprise version give you that makes it closer to being equivalent to AWS’s secrets manager?


HSM support and cross-region replication.


Customer support.


[flagged]


I see that _you_ are not familiar with AWS customer support.

I've been using EC2 for years, and every time I've had a problem, it's been solved with the first priority getting the (virtual) servers online. I've even had them waive a months' billing (<40 USD) as I was having trouble with the credit card company.

The only comparable experience that I've seen is Rackspace. They earn their "fanatic" moniker, I don't know if they still use it. But AWS is also fantastic and I highly recommend them.


If you bill is 40 USD, you are indeed not familiar with enterprise support and products.


$40 a month and EC2 is not “Enterprise level”. I am a developer for a small company and one of the AWS admins, but when I don’t want to be bothered with dealing with AWS support, I’ll punt to our outsourced AWS suppprt consultants and let them handle it.


I’ve had, at best, lukewarm experiences with AWS customer support. Anecdata it may be, but this seems to be largely in-line with the experiences of my peer group, professionally.


I'm familiar with AWS Enterprise support. They are excellent, and we routinely use them for figuring out issues or planning.


Not shilling for AWS, but I file at least 1 ticket a month. I haven't tried the phone option, but the web option works for resolving my complaints within 24 hours.

My use case might be different since the entire architecture is HA / ephemeral and I can spin up new instances etc while waiting on them.


On a high level, what types of issues have you had for which you have needed support? The only issue I’ve had was that we were using DAX wrong and they showed us the proper usage. It was a relatively new service st the time.


We have seen timeouts between EC2 and S3 and we needed their team to do a packet capture


We use parameter store, the thing that makes me nervous about it is there's no SLA on it. As it's free, what incentive do they have to improve it?

Additionally they might just retire it in favour of the secrets manager soon anyway. I bet the pricing on that would drop at that point too


Hey. I work for AWS.

Parameter Store isn’t going away and is still under active development.


So it looks more like a KMS system than let's say Chef Vault




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: