Detect terraform drift and avoid unwanted additions

[GuptaNavdeep1983]

Description

The runner module is designed with open for extension in mind, instead of requiring users inject all needs. Example of this approach is the module is creating roles and attaching the minimal required policies. Roles are output (exported) and users can add more policies based on the need. The drawback is that the role is managed and the policies that terraform attaches. But no other policies attached to the same role.

Risk

When adding policies manually to a role (for what reason) the drift will only been seen once by terraform when running a refresh state without auto apply. Next the policy becomes part of the state. Effect is that policies can be attached that have too many permissions and won't be detected since the drift is hidden. When you rebuild your environment the drift is gone, but for environments your continuous update the drift remains.

Detection / Solution

We are looking for solution to prevent this drift. One could be refactoring the module and don't allow the open for extension principle. This option we don't like. But so far, we have not found effective ways to protect.

Any suggestions from the community?

[maartenvanderhoef]

1. Attaching a iam policy (not inline) to a role is not causing drift which will be undone when running the philips runner module again.
2. When you use OIDC with your GH Workflows ( https://igorzhivilo.com/github-actions/github-actions-openid-aws/ ) the instance profile's permissions are practically irrelevant, unless you need to mount efs on boot.