#github-actions (2024-05)

I would probably create w workflow with following steps: • configure aws creds using this action • trigger pipeline with aws cli and used --variables to pass some envs form gha to codepipeline never done this, though, so might miss something

We use self-hosted GHA runners, deployed within VPCs. That way don’t have these problems.

For EKS, we use ARC - actions runner controller.

For non EKS, we use https://github.com/philips-labs/terraform-aws-github-runner

Lastly, just last month AWS announced this, but we haven’t tried it yet. https://aws.amazon.com/about-aws/whats-new/2024/04/aws-codebuild-managed-github-action-runners/

@Erik Osterman (Cloud Posse) that sounds really interesting, sadly I haven’t done that before, thanks for sharing Erik

do you have any other doc or link with some real example I can refer to?

All of it’s documented in our paid/commercial reference architecture

Which approach is most appealing? Maybe I can link you to something public

Looks like the idea of having a self hosted runner is the better since it allows to keep everything in github actions, sounds cleaner

@Erik Osterman (Cloud Posse) BTW, I received this comment form someone in my team when I suggested using self hosted runners:
I don’t think it’s a good idea to open any sort of direct network communication between GitHub and AWS private VPCs. I don’t think that’s a valid concern since we are already using aws credentials in github, so to me the security concerns are already being shared between github and aws, but what do you think guys I can respond to be consice and claer and get allowed

Are you free to join #office-hours ?

First problem, stop using any AWS credentials on GitHub. Use GitHub OIDC and IAM roles, so there are no hardcoded credentials.

Using CodeBuild/CodePipeline + GitHub is Identical to using GitHub + Self-hosted Runners, from a security/attack surface.

You need to test your software. Your software is on GitHub. You need to test your software on AWS where it will run. I don’t see a world (with end-to-end automation) where these two things are disjoint.

You should already have dev/staging/production, in entirely different AWS accounts.

Your CI technically, only needs access to test it in one of those accounts (or some other testing account).

Fwiw, dozens of our customers use this exact pattern, this is the first time I’ve heard the concern. Self-hosted runners is usually an enterprise requirement rather than concern.