YHacker News
points by raw_anon_1111 2 days ago | hide | 0 comments
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.

devendra1162 days ago | | | parent | | on: 47739946
something 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_11112 days ago | | | parent | | on: 47740486
Well 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.