search

thunderbird / appointment

Invite others to grab times on your calendar. Choose a date. Make appointments as easy as it gets.
https://appointment.day
Mozilla Public License 2.0
225 stars 8 forks source link

Scope GHA IAM Role down #576

Open malini opened 3 months ago

malini commented 3 months ago

Is your feature request related to a problem? Please describe. GHA currently assumes a role with too many permissions, way outside of what it should have.

Describe the solution you'd like We should change this so GHA assumes a scaled down role with just the permissions it needs, for each specific project.

Also, the role is set in this account's Secrets, as IAM_ROLE. The role itself isn't a secret and it can be something we want to view to verify the setup of our GHA is correct, so let's move this to an environment variable as well

Ideally, we should codify the role using IaC as well

jdbass commented 3 months ago

@malini @ryanjjung I'd like your thoughts on how to manage this. AWS recommends restricting by IAM action and by resource (ARN) but that challenging for Github Actions. There's a huge potential variety of actions we may wish to call and even enumerating the specific ones we currently use is a fair bit of work. Each service has unique action names and there's no real consistent convention to allow wildcards that are in any way accurate. Similarly, using resources means trying to build and maintain a list of wildcarded ARNs which isn't really any more convenient than using actions. Both are possible but, to my mind, extremely labour intensive and likely to result in failed GHA runs when a required update is overlooked due to a change in the IaC. The other option that comes to mind is instead to use tag based conditions and deny certain specific actions that are problematic. In other words, allow GHA to do any action on any resource as long as they are tagged as belonging to Appointment and managed by Terragrunt but block things like iam:PassRole and iam:CreateServiceLinkedRole. This does mean creating individual roles for each project/repo but that's generally a good idea anyway so that one repo's GHA can't break another one's deployed resources. I lean towards the second option as being a reasonable balance of flexibility and limiting scope but would like your thoughts as well.

Sancus commented 3 months ago

As a first pass I'd be happy with just scoping down to the services it needs access to. It certainly doesn't need any IAM user or role modification privileges for example.

malini commented 3 months ago

Sounds good, going with the second route of tagging our resources and giving permissions around those tags is reasonable, thanks!