As another commenter pointed out: you authorize the executor of the script, not the script itself.

Consider how an AWS instance runs code that is able to ... talk back to the rest of the AWS system.

For code that is not being directly run by a tethered meatball, use some form of workload identity [1].

When you are talking to another system that that can't understand your workload identity (legacy apis, etc.), keep those credentials in a tool like Vault[2], Secret Manager[3], etc. That system can/should handle credential rotation wherever possible, but it also ensures that the workload running the script is authorized to access the credentials in question. This is far superior to passing via env vars, but even that is better than hard-coding in the script itself. Oh, and using a memory-backed mount that contains those vars is better than env vars because there's less risk of leaking those when you fork.

Key points:

- externalize all secrets

- prefer workload identity

- prefer a workload identity aware secret store / manager

- fall back to fs mounted secrets and then env vars

[1] https://spiffe.io

[2] https://www.vaultproject.io

[3] https://docs.aws.amazon.com/secretsmanager/latest/userguide/...

edit: formatting now that I'm on a desktop

As sibling points out: Don't authorize the script, authorize whoever is executing the script.

Environment variables are an easy first pass at ensuring a script at rest isn’t dangerous.

Besides what the sibling comments said, it's very unlikely to that any script needs keys to the kingdom. Credentials should be created with limited access, just enough for the script to do its thing.

encryption based authentication (keys or certs) that can be revoked.

welcome to 1996.

Stuff like...tychotic helps prevent that :P