4 ms·
The only private key that my agents have access to are temporary AWS access keys to a dev environment with decently locked down permissions. I let it troublesh
by raw_anon_1111 6mo ago
The only private key that my agents have access to are temporary AWS access keys to a dev environment with decently locked down permissions.
I let it troubleshoot my web code using a temporary JWT in a dev environment using headless chrome and Puppeteer in a Docker container.
Everything else is in AWS Secrets Manager inaccessible by the IAM role the agent has access to.
I don’t store the temporary AWS keys in a file anywhere. They are in environment variables. All AWS SDKs and the CLI look in the environment variables by default.
I sure as hell don’t store API keys anywhere on my local computer.
- devendra116 6mo agosomething that you dont like about using AWS secrets Manager or think it should be handle differently? im researching around building a execution environment that handle the secret + actual execution, any input is appreciated
- raw_anon_1111 6mo agoWell since in my case all of the LLMs I use are hosted by AWS Bedrock, it means I can get away with only caring about AWS Access keys. If I need to store database passwords in secrets manager, I can just pass the ARN of the secret manager key in the connection string. I often don’t need to even do that and prefer to use the Data API to access Aurora Postgres/Mysql and that also uses the IAM permissions. Even for access to EC2 instances I use an IAM controlled Session Manager proxy to access it over SSH/RDP. But Secrets Manager just works. It’s a simple API/ClI command and the permission system to access it is very granular.