[slaughtr]

This seems like quite a lot of setup and hassle for what could be handled some other way with less fuss, like chamber[0] or Doppler[1]. Heck, even the classic .env seems like a better choice in every way.

What are the advantages to a configuration like this? Seems the HTTP interface with non-encrypted cache and separate agent situation isn’t something secure enough to satisfy most companies these days.

[0] https://github.com/segmentio/chamber

[1] https://www.doppler.com/

[gurchik]

I think the audience for this is someone who is already using AWS Secrets Manager, but wants to reduce their API usage (perhaps due to cost).

Chamber uses SSM Parameter Store, which for many cases is similar, but some people might have a preference for Secrets Manager. For example, a team might like the automatic RDS password rotation for Secrets Manager and decide to put everything there for consistency.

For Doppler, well maybe someone doesn't want to pay for it, or they'd rather control access to their secrets via IAM instead of through a separate tool.

[SamuelAdams]

Yes, we use something similar for debugging lambdas locally. We use Dotnet, and this library:

https://github.com/Kralizek/AWSSecretsManagerConfigurationEx...

Normally Boto uses the current account context to get secrets, but if we run a lambda as a local build, it uses this library to pull secrets from the actual dev AWS account.

This makes it easier to onboard new developers, reduces problems of figuring out what secrets to get for each lambda, etc.

Also if secrets are rotated in dev, local stacks get them automatically.

I am curious to see if this tool is remarkably different.

[banku_brougham]

Its no joke that AWS Secrets Manager calls add up. At my medium-size US web company, for our data lake account last month, KMS is the second highest line item after s3 service cost. S3 at 94% of total, KMS at 4% of total with Tax and Kinesis the remaining sizable components.

[drodgers]

Chamber can also use S3 + KMS as a backend, which reduces the API costs to ~0 and massively improves the scalability (since SSM has annoyingly low rate limits, or at least it did a few years ago when we last tried it).

[mac-chaffee]

The use-case seems to be intentionally narrow:

> The Secrets Manager Agent provides compatibility for legacy applications that access secrets through an existing agent or that need caching for languages not supported through other solutions.

[globular-toast]

I was going to say you can rotate secrets in secrets manager without redeploying all your services. But this caches the secrets so you'll still get stale results for up to 5 minutes by default. Not sure what the point is then.

[ak217]

> even the classic .env seems like a better choice in every way

That's a pretty thorough misunderstanding of the value that secrets management services provide. We can start with the idea of never storing secrets in files.

I think most companies also understand the difference between plain HTTP localhost loopback and transmitting secrets in plaintext over the network. There are many services that rely on localhost loopbacks for handling all kinds of sensitive data.

Chamber is great but generally relies on transmitting secrets via environment variables to the enclosed process and assumes that they will remain valid for the lifetime of that process. Part of the point of this tool is to provide a secrets cache with a TTL.

[lukeschlather]

This sounds an awful lot like an internal Amazon tool that predates AWS secret manager. It was actually really nice to use; the advantage comes if you always can rely on the daemon being available and you can just say "these machines have access to this secret." If you had to set up and configure the VM, maybe pointless, but it's intended for situations where you're deploying 1000s of VMs with many teams and some centralized team is preparing the machine images you're using.