A way to manage access around who can edit contents of `.github/workflows/`

[timharris777]

Enhancement: Provide role separation around who can edit contents of .github/workflows/

Reasoning: In an organization setting you have a lot of people who have write access to repositories. Add github actions workflows and secrets manager (think org level secret manager when it is released) and every person with write access could change a workflow file or create a new workflow file to print out the contents of a secret. Being able to limit the people who can edit workflows would be a huge plus in the security front.

@ds0440 @josephshanahan-cfa

[TingluoHuang]

@chrispat from the product team for feedback.

[chrispat]

@timharris777 limiting of editing the workflow file will not help with security. If you are running any code as part of your build and someone can change that code they can potentially export secrets by dumping process memory.

[josephshanahan-cfa]

@chrispat, what you are saying is a helpful callout, but please consider this:

The scope of a secret is limited to a step.

If a secret's scope is limited to a step, then secrets are isolated and contained to that specific step. For example, in our build process the only step that would allow someone to edit it and dump process memory (as you said) is a step that does a ./gradlew build, and this step contains zero secrets. This step builds an artifact and then passes it to another step that deploys the artifact. Only the step that deploys has access to a secret.

This makes me think the enhancement request should also ask for role separation around who can edit contents of the entire .github/ folder. Anything in this directory would be protected from unprivileged editing and the malicious dumping of process memory. Since the .yml files are in this folder and would also be protected, it would not be possible for someone to edit the steps and change the scope of secrets.

[chrispat]

@josephshanahan-cfa the scope of a secret is a job not a step meaning that the secret is active in the memory of the runner for the scope of the job in which it is referenced.

Your gradle example is a great one here as it runs code that is part of the repo that anyone with write access to the repo can modify. This means that they could add something to dump the process memory for the runner which has all of the secrets being used in that job. Have a separation of roles is false security when you are talking about config as code and CI that runs arbitrary code.

[josephshanahan-cfa]

So you are telling me that any 3rd party action can dump all of my secrets, regardless of the step? Could you provide an example for how to do this across steps as you mentioned?

[chrispat]

I am saying that any code you run during your CI could potentially dump all of the secrets that are referenced in the execution scope which is a job. If you are running your job in a container this becomes significantly harder because the runner is not inside that container. However, for platforms like MacOS that don't support containers at all or on Windows where containers are not practical for many CI needs that is not an option.

[josephshanahan-cfa]

Thanks for the response @chrispat, could you please provide an example for how to access secrets across steps in an ubuntu environment that is not using containers?

[chrispat]

@josephshanahan-cfa I am not sure what you mean. Are you asking for an example of how you would dump process memory and then read the strings out of it?

Here is an article on how to dump the process memory of a .NET process https://devblogs.microsoft.com/dotnet/collecting-and-analyzing-memory-dumps/

[josephshanahan-cfa]

Yes, that would be helpful. From the GitHub Actions docs it says:

A job contains a sequence of tasks called steps. Steps can run commands, run setup tasks, or run an action in your repository, a public repository, or an action published in a Docker registry. Not all steps run actions, but all actions run as a step. Each step runs in its own process in the runner environment and has access to the workspace and filesystem. Because steps run in their own process, changes to environment variables are not preserved between steps. GitHub provides built-in steps to set up and complete a job.

https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsteps

This documentation makes it sound like the step runs in its own process. It sounds like you are saying that steps are sharing process memory.

Could you give me an example as you mentioned of dumping process memory and then reading strings out of it? Specifically, where I would be able to see the secrets declared in one step, in another step (All in the same job).

[chrispat]

Steps are run in their own process space and its own process memory, but, they are all run under the same user context and as a user you can read the process memory of other process running in your context. This is essentially how a debugger works, you run the debugger as you and attach to another process. If you are an admin on the machine you can read the memory of essentially any process on the machine.

I don't have a working example right now but I have seen it done.

[bryanmacfarlane]

@chrispat is correct. Essentially it's user code running on a machine as admin. Not really securable. Which means you have to trust who can edit your workflow file or in the case of something like deploys etc, your workflows and scripts could be in another repo than the code / containers being built and tested independently by developers. This is also why we don't send secrets to forks.

[davidkarlsen]

Also one should be critical to actions found on the marketplace. These could steal information and/or do bad actions in general.

[timharris777]

Hey guys, we understand that anyone who can edit the workflow file can possibly dump secret contents.

Our ask is that you provide role based separation of who can edit the contents of the .github/ folder or the .github/workflows folder. For example, looking at the current roles of read, triage, write, maintain, and admin-- maybe the maintain and admin roles could have access to update the folders in question. This would prevent everyone who only has write access to the repo from being able to edit the workflows.

Separately, Gitlab allows per folder permissions in addition to repo level read/write permissions which would solve our issue but Github does not seem to have this capability. Is that on the radar at all?