Yeah, weird for them to do that. Managing credentials like that sucks even from an ergonomics standpoint.

In practice, it's pretty normal to use OIDC to authenticate Github Actions to AWS:

https://docs.github.com/en/actions/deployment/security-harde...

Ok yeah, looks like they recently added OIDC support: https://docs.digger.dev/cloud-providers/authenticating-with-...

They should update the main readme to include this under Features, and also call it out in the demo files.

> It sure looks like AWS admin credentials are shared with Github, and also available to anything else in the diggerhq/digger action

I am a co-founder of Terrateam[0] which is a Terraform CI/CD as well. At the end of the day, you need to execute something to do these operations and having this component open source is important for auditing purposes. For Terrateam, we lean heavily into GitHub Actions so GitHub is at least managing any secrets and runs. One challenge is users could pin the Action that we publish to a specific version, but we also update it regularly and communicating to customers to update it is a challenge.

[0] https://terrateam.io

One of the founders here You could also use OIDC so no need to share keys

https://docs.digger.dev/cloud-providers/authenticating-with-...

Any CD is going to require some kind of authentication key. To minimize the surface area of a potential leak, create a user in AWS for the tool, only grant it access to the resources needed, and then create a key for that user to place in your CI. You should also enable audit trails in your AWS account so you can monitor for unusual activity.

You should create a role, not a user IMO. Also how do you manage that role/user? Via terraform?

I do similar with K8S and RBAC. The most common action in a repo is going to be to update a deployment with a new image or resource config, so that’s all it can do.

Still need a more permissive role to manage the cluster in other ways but you can isolate that and limit access to its repo.

The only IAM-safe way is to run context-aware terraform plans so the environments cannot ever CRUD out of scope. For example, an application-centric approach might use an ABAC constraint and temporary credentials (perhaps via OIDC, but most OIDC integrations lack local privilege separation; instance roles are far more secure) and making sure events are bound to the environment they are allowed to be executed in.

This does require something that should essentially be embedded in your environment or account vending machine, otherwise it becomes very cumbersome to maintain.