So the point of this is just to cache secrets, to avoid caching them in your app memory?
Seems like kinda a niche threat model, if your app is already compromised to the point where it's secret cache can be read, it seems likely that the attacker could also pivot to just read from the cache, or use the instance credentials to read from secrets manager itself.
If I looked at what this does and none of the surrounding discussion/documentation, I'd say this is to simplify using secrets manager properly more-so than any security purpose.
To use secret manager "properly", in most cases you're gonna need to pull in the entire AWS SDK, maybe authenticate it, make your requests to secret manager, cache values for some sort of lifetime before refreshing, etc.
To use it "less properly", you can just inject the values in environment variables but then there's no way to pick up changes and rotating secrets becomes a _project_.
Or just spin this up and that's all handled. It's so simple you can even use it from your shell scripts.
For anything we inject secrets in via env vars (which really is only supported by ECS, maybe EKS?), it is easy to add a lambda to kick off a nightly ECS restart. Easier if you are already using the AWS CDK for tooling.
The purist in me thinks restarts are a hack, but the pragmatist has been around long enough to embrace the simplicity.
Adding another dependency/moving piece that AWS could drop support or it could just break also steers me away from this.
For Lambda, processes should be getting swapped fast enough and you also normally load during a cold start only. I could see some argument there around improving cold start performance, but would need some testing.
No, the point is to get sensitive data out of the env variables, which nowadays get stored in plaintext in an .env file or similar. This is a solution for storing and retrieving secrets using AWS credentials. Essentially an online password manager for your application.
But AWS Secrets Manager does that already, without the Agent. It seems like the main value-add of the Agent is that you don’t have to manage a cache in your application code but still get the performance/cost advantage of having one.
So you don't have to manage a cache, but you do have to manage a network-connected sidecar service? You can make the "N programming languages" argument for why this isn't just a library, but they already have the aws-sdk, and Secrets Manager clients in that SDK, what advantage would this hypothetically have over a caching mechanism native to the SDK and internal to the application process?
The Security section of the Readme actually recommends using the SDK when it is a viable option. Seems like this is meant to fill a small gap for niche scenarios where that isn't an option, for some reason.
Yeah I think this line should really be at the utter-tippy-top of the README
> The Secrets Manager Agent provides compatibility for legacy applications that access secrets through an existing agent or that need caching for langages not supported through other solutions.
This does not appear to be an interesting, state of the art, purported best practices way to access Secrets Manager; its just a shim for legacy apps. And that does make sense, as there are many languages which do not have SDKs available, but do have an HTTP client library; though I question how much of the demand for something like this comes from how insanely complex authenticating with the AWS API is.
What about the credentials used to access AWS credentials? I think there's a good case for centralised credentials where they are shared across applications, though I would seriously question the need to share them across applications. But what you're achieving here as far as I can tell is just making secret retrieval more convoluted (for both devs and hypothetical attackers). Not to beat the dead horse, but obscurity != security.
When you deploy your code to AWS lambda or EC2 the code can simply access the appropriate secret stores as dictated by the IAM policy. If you haven't bought into AWS as a whole you're right that there's no good reason to use secret manager.
If you're in AWS, you get credentials from the metadata service.
If you're outside AWS, workloads assume roles using OIDC. If you still have access keys, generally speaking, you're doing it wrong.
Technically true, but in practice the role means you don't have to care about them. They're an implementation detail that's managed by AWS. Could be flying mice for all the app dev cares.
Sure, under the hood it is still access keys. Very temporarily defined access keys that going the normal happy path means you're not directly handling. What I'm really meaning by my above comment is you're not configuring your workload with ACCESS_KEY=abc123 SECRET_ACCESS_KEY=xyz789.
They aren't configured, but they're not as temporary as one might hope (i.e. they don't rotate on every read, for example), and it's pretty trivial set of exploits to leak them, especially in Kubernetes clusters with incorrectly configured worker nodes.
A much better solution would be for AWS to offer a domain socket or device inside VMs that will sign requests, such that the private material isn't even available to leak.
There are no credential, you are supposed to use identity-based auth: your lambda / ec2 / eks pods etc have a IAM role, so there are no secret in any form
So imagine you have some number of cron jobs which require a bunch of secrets and these things fire every minute or 30 seconds or what have you. You could save as much as $0.25 a month!
I think the point is less for apps, and more for the infrastructure that deploys apps (think: a Kubernetes control-plane), when that infrastructure depends on secrets from AWS but does not itself live within AWS — i.e. the "hybrid cloud" use-case.
> or use the instance credentials to read from secrets manager itself
Usually apps don't actually have instance credentials like this, but rather the thing deploying the app does, and that thing then injects just the secrets the app actually needs into the app's sandbox.
I am working on a secrets manager for the paranoid, and part of the idea is to do this, yes. However, most of the idea is to get secrets off of your disks and out of your git repos. That's mainly what Hashicorp Vault and AWS Secrets Manager do for you. They turn authenticated roles into the ability to access your secrets so they don't go in a plaintext file.
Reading this I am confused about what exactly this is meant to solve as well.
Given that services like Lambda and ECS are already setup to be able to pull from secret manager natively and provide it as an environment variable.
What is the threat model that this is actually going to solve? At best it seems like security through obscurity, it removes the low hanging fruit of looking at ENV but if your application has the rights to use this than if someone gets into your container they can still get your secret.
What am I missing about the big advantage of this and why it was made?
The motivation is in the project’s readme, down at the bottom.
The tl;dr is that this is for legacy software where you can make HTTP calls to retrieve a secret, but for some reason cannot use the AWS SDK. If you can use the SDK, you should use that instead of this proxy.
Seems like kinda a niche threat model, if your app is already compromised to the point where it's secret cache can be read, it seems likely that the attacker could also pivot to just read from the cache, or use the instance credentials to read from secrets manager itself.