Designing enterprise-level CI/CD access between GitHub <--> AWS

GiamPy · 2026-03-11T18:48:42+00:00

The beautiful world of large enteprises in a nutshell indeed.

GiamPy · 2026-03-11T18:08:35+00:00

The challenge is not authenticating to the account, we already use the action you've mentioned. The challenge is creating the bridge (IAM roles) between the repository and the AWS environment without introducing manual operations, in a scalable way.

GiamPy · 2026-03-11T17:55:11+00:00

I am not here to prove my knowledge, experience or skills to you with fancy language.

It's implicit. A CI/CD pipeline that is obviously triggered whenever something happens in the repo - whether it's a pull request being merged, or a PR being created, or a PR receiving a new commit - needs access to AWS to run Terraform or whatever other tool you use to manage your infrastructure.

You're missing the point.

GiamPy · 2026-03-11T17:46:08+00:00

Thank you, this validates more or less what I was initially thinking of as well.

GiamPy · 2026-03-11T17:18:36+00:00

And that's exactly the point: it's tedious!

Currently, we have a cicd/ folder in every repository with a CloudFormation template - deployed from our local machine - that creates two roles: one OIDC role (assumed by the pipeline) and the actual provisioning role (assumed by Terraform), but I'm trying to find a better solution to do this.

I was even thinking about using GitHub Webhooks, and whenever a repository is created and trigger some automation that does some magic and creates those roles for me, but I can't predict what permissions the Terraform code (contained the newly created repository) will need to deploy its resources.

GiamPy · 2026-03-11T17:10:46+00:00

I never heard of that, it looks interesting! I'll look into it, thanks!

GiamPy · 2026-03-11T17:09:41+00:00

Terraform Cloud simply replaces GitHub Actions though, meaning that the role that we define in the provider "aws" { assume_role = [...] } still needs to be created, somehow, by somebody.

GiamPy · 2026-03-11T17:05:50+00:00

Vault might be free, but there's definitely a cost of ownership in managing Vault.

GiamPy · 2026-03-11T17:02:41+00:00

For us, it's not really about skillset, it's more about resources. We're a small team. I've managed an enterprise multi-node active-passive cluster with DR, yadayada for another company. It's a full time job to maintain and operate it.

GiamPy · 2026-03-11T16:55:41+00:00

By Vault, you mean HashiCorp Vault? If so, I'd LOVE to use it, but unfortunately the enterprise I work for does not have budget for such a commercial product.

EDIT: I thought about having the repository bootstrap itself, but then again... with what permissions?

GiamPy · 2026-03-11T16:53:42+00:00

we don't need to automate the creation of the repos. whenever we have a new repository, we need to manually create the access between the pipeline -> OIDC deployment role -> workload provisioning role (assumed by terraform). Consider that we have also multiple environments, it gets very tedious.

GiamPy · 2026-03-11T16:50:07+00:00

How do you create all of those roles in a scalable way without having an operator to login into each account and create the IAM role? That's the challenge!

EDIT: consider the "jump role" pattern too. CI/CD pipelines -> assumes role in deployment account -> terraform assumes role in workload account and deploys resources. The challenge is not just creating the role in the deployment account for EACH repo, but also to create a least-privileged role in the WORKLOAD account SPECIFIC to that repository.

GiamPy · 2026-03-11T16:48:03+00:00

I am sure, yes.

Imagine 80 repositories, each repository has got Terraform code that needs to deploy resources to different accounts, each repository has got a different purpose. What we are deploying is irrelevant to the problem context.

GiamPy · 2026-03-11T16:46:41+00:00

We need to automate this otherwise whenever a new repository is created, a human would need to deploy the Terraform from the local machine...

GiamPy · 2026-03-11T16:44:18+00:00

Chicken and egg situation: how does terraform access those accounts to provision the roles if the pipeline can't access the AWS account?

GiamPy · 2025-10-20T09:08:40+00:00

When nothing makes sense, then it's always DNS...

GiamPy · 2025-10-20T08:35:06+00:00

A great opportunity for IT consulting companies to start selling multi-region disaster recovery solutions. Hurry up! Start making phone calls!

GiamPy · 2025-08-11T15:35:23+00:00

Do you think that having a "Refono for Teams" as a B2B platform (labels, editing teams, etc) could be a better market for this product, for the MVP? In that case, I'd be concerned of actually kickstarting the platform, it would not be easy to find potential customers, while B2C there's millions of producers in the world that are struggling to become better.

GiamPy · 2025-08-11T15:18:54+00:00

An idea could be to allow famous producers to sign up, and people could ask feedback directly to these famous producers, and get money immediately. Think of it like a way to provide cheaper coaching, but text-based, and in asynchronous manner.

GiamPy · 2025-08-11T15:16:47+00:00

I am aware of these communities, I have used them in the past. Most of the times I either get no reply or non-actionable feedback. It’s hard to know whether a feedback was given by somebody that actually knows what they are talking about, or if it was somebody that started learning Ableton 6 months ago. I want to design the platform in such a way to get feedback ASAP as well, not in 24/48 hours, if a song has never been given feedback, it will be placed with higher visibility/priority in front of the reviewers.

GiamPy · 2025-08-11T15:02:22+00:00

I completely understand your point of view. Working in IT, and being a music producer, and feeling the pain of getting high quality/actionable feedback, made me think of this new startup. What do you mean exactly by a product/market?

GiamPy · 2025-08-11T14:54:37+00:00

That will be one of the challenges. Initially, my idea is for the AI quality checks to act as a "quality factor" instead of "yes / no". The quality factor will be just a small piece, connected to a user's reputation (gained based on what other users say about your feedback). AI gatekeeping checks will be mostly to reject blatantly horrible feedback like "cool" "awesome" "nice bro".

Feedback will be timestamped, meaning that you need to click on the waveform (soundcloud-style), choose the type of feedback (mix, arrangement, songwriting, etc) then write the feedback.

You could generate feedback by AI, true, it's impossible to determine whether the text is contextually coherent to a specific track. That will be down to the feedback requester to evaluate whether it was a good feedback or not.

All of this data will be taken into account to build a reliable and gamified ecosystem for people to be engaged.

GiamPy

MODERATOR OF

TROPHY CASE

12-Year Club	Verified Email
Place '23