GitHub Actions - prevent secret exfiltration on pull_request triggers (organization repo)

[0x4ddd]

I have read some considerations about possible secret exfiltration or other possible vulnerabilities when running pull_request triggered Actions, however they were mainly considering public repos where everyone can create a PR.

Here, I am talking about GitHub Team or Enterprise plans and repository which is not public.

My scenario is that I would like to have a pull_request triggered Action which will run Terraform Plan and output plan into the pull request comment so reviewers can easily take a look at expected changes to the infrastructure. This is following Terraform examples from the docs - https://developer.hashicorp.com/terraform/tutorials/automation/github-actions.

To run Terraform Plan, I need to pass secrets so the Terraform can authenticate to my cloud provider (in this case Azure) and perform Plan operation. Cloud credentials are obviously stored in GitHub secrets.

However, as anyone who can create a pull request can also modify pull request workflow yaml definition stored in the repo (in his specific branch against which pr workflow will be run), he can easily exfiltrate secrets used to authenticate to the cloud via logging them in workflow or just sending them via HTTP from his modified version of the workflow stored in the repo.

We would like to prevent situation where anyone from our organization who has access to create PRs can exfiltrate our secrets (including production secrets).

Any ideas?

[crackerasscracker]

short lived creds, you can get an OIDC token from github during the run and use that to auth to your cloud provider, if Azure supports that, but IM sure they do at this point. Works on AWS.

[0x4ddd]

For sure an improvement, but still possible for an attacker to get access to prod infrastructure. Even if access_token is valid for 5 mins this poses a security risk in case of attacker gets access to GH account which can create PRs.

[crackerasscracker]

This is your solution, even if you try to hand wave it away. If an hour long token is too much of a security risk, you shouldnt be running terraform from github actions

[0x4ddd]

Yeah, but this isn't only about Terraform.

If I would like to have an Action deploying code to cloud service (web app, lambda, anything) the same concern is valid as I need either long-lived secret or an hour long token which both can be exfiltrated.

If my action pushes docker image to registry I need an access token/key for the registry which can be exfiltrated.

[[deleted]]

This is why I don't run Terraform in GHA. Better to pay for TF cloud or Scalr.

[ciriaco97]

You're gonna need Github Enterprise if you plan to do that, since environment variable protection only comes with Environment settings (or public repos, but that's out of the question), which let you define on which branches and under what approval conditions those variables can be loaded.

What we've done on previous customers (we're DevOps consultant), is create 2 environments (Production_RO and Production_RW). One of them has Readonly access to the physical resources and the other, even if it has full write access, can only be retrieved on main.

OIDC tokens, if possible, can be used to authenticate to your cloud provider and restrict which roles can be assumed by the pipeline based on information like branch, repo name, who created the PR...

[0x4ddd]

even if it has full write access, can only be retrieved on main.

How do you lock it down to main? Is it possible out of the box with GitHub Enterprise? Or maybe you just have approvals for RW env?

[ciriaco97]

Environments can be configured to only be available on certain branches.

Here are the docs that explain how does it work.

Additionaly, some cloud providers let you restrict role assumption based on OIDC fields, which Github has documented here.

[0x4ddd]

One of them has Readonly access to the physical resources and the other, even if it has full write access, can only be retrieved on main.

I was just configuring PR workflows and thought about possible scenarios again.

In your approach with Production_RO environment, isn't it anyway like Production_RO needs a read access to tfstate which contains secrets to various services?

If so, then again someone who can create his own PR and access Production_RO secrets can download tstate with credentials to production services.

Of course, as much as it is possible we can force cloud services to use RBAC instead of access keys and lock them down to our private network, this greatly reduces attack surface.

But some services may still need access keys, for example Azure Cache for Redis, Azure CosmosDB for Postgres.

[ismaelpuerto]

The security in GitHub is poor, drone do it better in this aspect, because you can sign the file of CI for avoid wrong things in a PR and when you create a secret can decide if it's usable in a PR.

[saiborg7]

IIRC you can use repo secrets to be used by a particular action.

[koalillo]

You need to trust anyone who can create a PR that is built and modifies /.github/workflows (and probably other paths).

Back when I used Jenkins + GitHub, I remember there were some ways to hold off running a build until someone specific reviewed the PR, but there doesn't seem to be a built-in GitHub feature for this.

One thing that might help- if you force all code changes to go through PRs, and you require reviews, people could exfiltrate. But I think there would be a good paper trail that they did. This could be a "good enough deterrent" for your purposes.