[thinkmassive]

One of the major security issues with running terraform in your CI/CD pipeline is that it usually needs admin permissions to your entire cloud environment. To avoid this you need the pipeline to pass parameters to an internal process that actually applies the changes.

Digger makes it sound like it might address this:

> Digger runs terraform natively in your CI. This is: Secure, because cloud access secrets aren't shared with a third-party

From the Github+AWS demo:

> 4. Add environment variables into your Github Action Secrets (cloud keys are a requirement since digger needs to connect to your account for coordinating locks) AWS_ACCESS_KEY_ID & AWS_SECRET_ACCESS_KEY

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

[mikedelago]

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...

[thinkmassive]

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.

[izalutski]

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

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

[sausagefeet]

> 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

[oneplane]

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.

[evantbyrne]

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.

[ljm]

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.

[klysm]

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