Org-wide deployment

[automartin5000]

Has anyone attempted to use this cross-org? Should the idea here be to deploy a stack to every account? Or should the runners assume a role into each account? And if the answer is assume a role, how do you control access to roles? I noticed there's a comment about OIDC and repo names in IAM roles, but that seems like it would be challenging to automate/scale.

[kichik]

If you're talking about multiple AWS accounts in the same organization, then yes, you probably want OIDC to provide access to multiple accounts. Automating this would probably require a hook-up to whatever is vending those accounts. Ideally you create your AWS accounts with CDK and then part of that process can be setting the names of repos you wish to have access to that account. You can then use something like aws-cdk-github-oidc to automate the role creation.

If you choose to deploy a stack to every account and use instance roles, you will have a similar issue of installing the runner app on only the right GitHub repositories so they don't get access to other runners.

It depends on your current setup, but I would think in general a single runner instance with OIDC would be simpler to maintain.

If you are talking about using the same runners across multiple GitHub organizations, then that's only recommended on GitHub Enterprise Server (on-prem) because it requires making the runner app "public". In that context, public only means in that GitHub server. If you choose to make your runner app public on GitHub.com, which is technically possible but not recommended, you would give anyone on GitHub the option to install it on their repository. If they install it on their repository, then they can use your runners. That's why on GitHub.com, the only recommended option to use the runners cross-organization would be multiple runner apps. At the moment each app requires another deployment of the GitHubRunners construct.

[automartin5000]

If you choose to deploy a stack to every account and use instance roles, you will have a similar issue of installing the runner app on only the right GitHub repositories so they don't get access to other runners.

This is sort of what we do today via StackSets and IAM Users with credentials pushed to GitHub. Except we don’t put any restrictions in on who can deploy to which account.

It depends on your current setup, but I would think in general a single runner instance with OIDC would be simpler to maintain.

I see two problems with this approach:

1. Now there’s gonna be one central set of Runners that we’re gonna have to manage for the whole company to make sure there’s enough capacity for all teams. It’s like Jenkins v2
2. We have to come up with some kind of easy-to-use interface for maintaining a list of repo-to-account mappings that are deployed as part of the CDK app

[automartin5000]

Another option I was considering was one GitHub app and set of runners per team. Seems like a middle ground between option 1 and 2. Then each team could maintain their own set of runners via an easy to use “bootstrap” template repo

[kichik]

Another option I was considering was one GitHub app and set of runners per team. Seems like a middle ground between option 1 and 2. Then each team could maintain their own set of runners via an easy to use “bootstrap” template repo

As long as the labels don't conflict between different runners, I believe that should work. You would have to copy over the app keys to each runner stack, but that should be feasible.