An environment variable on a Lambda function or a container task is not hidden. Anyone holding permission to describe that resource can read its configuration, and configuration includes the variables. That turns a read-only role, the kind handed out freely for troubleshooting, into a way of collecting database passwords. CISA’s secure by design guidance argues for eliminating whole classes of problem rather than managing them, and this is one you can eliminate.
Who can actually read your configuration
The permissions involved sound harmless in a policy document. Reading a function’s configuration, describing a task definition or viewing a launch template are all routine operations granted to developers, support staff and monitoring tools. None of them look like access to a credential until you notice what the configuration contains. Testers check this early because it needs no exploitation: with a low privilege role, list the resources, describe each one, and read what comes back. It is often the fastest route from a limited foothold to a database.
See also: Life’s Simple Lessons
What a secrets service changes
Secrets Manager and Parameter Store move the value out of configuration and behind their own permission and encryption model. The application receives a reference and retrieves the value at runtime, so the credential exists in memory rather than in a resource description. That gives you three things you did not have before: an audit trail showing every retrieval, the ability to rotate a value without redeploying, and a permission boundary distinct from the one governing the compute resource. The cost is a small amount of latency and an API call, which caching handles.
“Moving secrets into a vault and then granting the application role permission to read every secret in the account achieves very little. Scope each role to the specific secrets it needs by name, and check the key policy as well, because permission to decrypt with the key is the permission that really matters. I see the first half done properly and the second half skipped constantly.”
William Fieldhouse, Director, Aardwolf Security Ltd
The places secrets leak anyway
Even a well configured estate leaks through the edges. Build logs print environment variables when a script is verbose. Infrastructure templates put values in outputs, which are readable by anyone who can describe the stack. Container images embed configuration files from a build stage that was supposed to be discarded. Application error pages include the connection string in a stack trace. Each of these bypasses your vault entirely, which is why secret scanning belongs in the pipeline and in your logging platform rather than only in the code repository.
Checking it properly
Test from the position of a modest role rather than from an administrator’s console. Assume a developer role, enumerate the resources it can describe, and see what falls out. An AWS security review does exactly this and reports the chain rather than the individual permission, which is what makes the finding land with the people who grant those roles. Keep regular vulnerability scans running alongside, since a compromised instance gives up whatever it holds in memory regardless of how carefully the secret was stored.
Frequently asked questions about AWS secrets
These questions come up when a team moves credentials out of configuration.
Is Parameter Store good enough, or do you need Secrets Manager?
Parameter Store with encrypted values covers most needs at lower cost. Secrets Manager adds managed rotation and cross-account sharing, which matter for database credentials and for secrets shared between teams.
Should containers receive secrets as files or variables?
A mounted file read at startup is generally safer, because it is not exposed through resource descriptions and not inherited by child processes. Either way, retrieve at runtime rather than baking the value into the image.
