Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Strongbox: a secret manager for AWS

schibsted.github.io

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Strongbox: a secret manager for AWS

#31

Post by eropple »

otterley wrote: post #28
ejcx wrote: post #14

If you're all in on AWS, just use parameter store. This scheme is just CredStash, and so is parameter store under the hood.

Even if you're not all-in on AWS, you can use Parameter Store for a trivial sum. The latency might be a bit higher, but in most cases it shouldn't matter since secrets usually have a nonzero TTL associated with them.

If you're not using AWS, the use of Parameter Store (or Credstash) becomes a turtles problem--because you need to provision AWS credentials. At that point, whatever you provisioned AWS credentials into might as well store your other secrets, too.

If you are using AWS, EC2 itself is a trusted third party that grants the appropriate permissions for your executing system (container, instance, whatever).

Re: Strongbox: a secret manager for AWS

#32

Post by ejcx »

eropple wrote: post #31
otterley wrote: post #28

Earlier quoted context omitted.

Even if you're not all-in on AWS, you can use Parameter Store for a trivial sum. The latency might be a bit higher, but in most cases it shouldn't matter since secrets usually have a nonzero TTL associated with them.

If you're not using AWS, the use of Parameter Store (or Credstash) becomes a turtles problem--because you need to provision AWS credentials. At that point, whatever you provisioned AWS credentials into might as well store your other secrets, too. If you are using AWS, EC2 itself is a trusted third party that grants the appropriate permissions for your executing system (container, instance, whatever).

While this is true, it's something you can work with in the future, and it defined a secrets process earlier rather than later

If you do nothing you end up stuck with secrets in git history and you essentially have to roll them all.

So, my advice is generally SSM with no security is better than no secrets Management solution.

Re: Strongbox: a secret manager for AWS

#33

Post by bespoke_engnr »

stiankri wrote: post #12
bespoke_engnr wrote: post #7

Charging $1 per secret is interesting. I wonder if that will affect how people design their application. We've had a pretty splendid experience with Vault so far, so I'm not exactly in the market for another solution, but this looks interesting. I assume you started development on this because Vault et al didn't exist yet at the time? Or was there another driver?

Strongbox was designed prior to AWS Parameter Store, and took its inspiration from projects like Fugue CredStash and similar AWS KMS based projects. While there are certainly pros and cons with the different approaches, which you can see in the linked comparison table, I think one of Strongbox' strengths is that it is easy to set up, and you get a lot of convenience functionality related to secrets management. Not ha…

Thanks for the additional explanation, and for clarifying RE: $1/service; that makes sense.

Re: Strongbox: a secret manager for AWS

#35

Post by eropple »

ejcx wrote: post #32
eropple wrote: post #31

Earlier quoted context omitted.

If you're not using AWS, the use of Parameter Store (or Credstash) becomes a turtles problem--because you need to provision AWS credentials. At that point, whatever you provisioned AWS credentials into might as well store your other secrets, too. If you are using AWS, EC2 itself is a trusted third party that grants the appropriate permissions for your executing system (container, instance, whatever).

While this is true, it's something you can work with in the future, and it defined a secrets process earlier rather than later If you do nothing you end up stuck with secrets in git history and you essentially have to roll them all. So, my advice is generally SSM with no security is better than no secrets Management solution.

If you do nothing, you end up with secrets manually provisioned by logging into a machine and splatting out a configuration file. Which is a more secure solution than a turtles-problem parameter store.

Re: Strongbox: a secret manager for AWS

#36

Post by res0nat0r »

kompiuter wrote: post #30
scrollaway wrote: post #24

Earlier quoted context omitted.

I don't understand why so few people talk about ParameterStore. It's a fantastic tool, and AWS does such a terrible job of advertising it.. hidden under SSM, an offering non-enterprise users probably don't care about, and giving the wrong impression that it's only for EC2. ParameterStore should be part of KMS instead I think.

You're right. I've never even heard of ParameterStore before.

Exactly. I was wishing for an AWS based cli accessible credstore service for a while and didn't even know this existed until just the other week.

One big problem with AWS and their incremental features / improvements is you never hear about much of it, or its buried in a post from Jeff's blog that you have to watch like a hawk to keep up with.

Re: Strongbox: a secret manager for AWS

#37

Post by ejcx »

eropple wrote: post #35
ejcx wrote: post #32

Earlier quoted context omitted.

While this is true, it's something you can work with in the future, and it defined a secrets process earlier rather than later If you do nothing you end up stuck with secrets in git history and you essentially have to roll them all. So, my advice is generally SSM with no security is better than no secrets Management solution.

If you do nothing , you end up with secrets manually provisioned by logging into a machine and splatting out a configuration file. Which is a more secure solution than a turtles-problem parameter store.

You're assuming readers are managing snowflake servers, and I'm assuming they are in an containerized/autoscaling/more modern environment.

SSM wins for mine. I think you're right that the file approach wins for yours.

Re: Strongbox: a secret manager for AWS

#38

Post by senand »

res0nat0r wrote: post #36
kompiuter wrote: post #30

Earlier quoted context omitted.

You're right. I've never even heard of ParameterStore before.

Exactly. I was wishing for an AWS based cli accessible credstore service for a while and didn't even know this existed until just the other week. One big problem with AWS and their incremental features / improvements is you never hear about much of it, or its buried in a post from Jeff's blog that you have to watch like a hawk to keep up with.

I had/have the same problem.

Since a while, I subscribed to „AWS this week“ on YouTube from a cloud Guru. This is just 5 minutes, and you have a good idea what‘s going on. (I have no affiliation)

Re: Strongbox: a secret manager for AWS

#39

Post by eropple »

ejcx wrote: post #37
eropple wrote: post #35

Earlier quoted context omitted.

If you do nothing , you end up with secrets manually provisioned by logging into a machine and splatting out a configuration file. Which is a more secure solution than a turtles-problem parameter store.

You're assuming readers are managing snowflake servers, and I'm assuming they are in an containerized/autoscaling/more modern environment. SSM wins for mine. I think you're right that the file approach wins for yours.

I'm assuming readers are just starting out, where auto-scaling and bloggable container architectures make very little sense. Configuration management is a prerequisite for those. That said, having a CM in place also makes the please-invest-in-us container ecosystem much less attractive, given that you can easily fall back to singleton-container-on-an-instance patterns (which is a great one for deployment regardless of your approach).

To that end, yes, their servers are probably hand-rolled or provisioned with minimal scripting like Ansible. And so manual secret deployment is to be expected.

If somebody is attempting to autoscale without having this solved already, they are making mistakes.

Re: Strongbox: a secret manager for AWS

#40

Post by auspex »

stiankri wrote: post #23
rad_gruchalski wrote: post #19

Earlier quoted context omitted.

Sure, but what if the language I'm using is not high on your priority list? Isn't it easier to add a high level rest api?

That is certainly one approach we have looked at. The question then is where would you run the REST API? As a side car, as a separate service, e.g. using AWS API Gateway and Lambdas? If you look at the work required to write a simplified read-only client using the AWS SDK for KMS and DynamoDB, while perhaps a bit more work than integrating with a REST API, it is not that far off, which is why we are considering that…

Any of the suggestions above would most likely work. Running an API sidecar or separate service would just be the cost of exposing the REST API.

I could definitely envision people deciding against using your key store when comparing to something like Vault based just on the fact that you limit extensibility with no API.

Post reply on HN