Showing results for 
Search instead for 
Did you mean: 
Copilot Lvl 3
Message 1 of 3

Allow secrets to be shared with trusted Actions

This is a proposal to solve a problem related to


I think Github Actions did the right thing by making the $GITHUB_TOKEN read-only and secrets unavailable for forks for security reasons, but this can be a big limitation. Short of making a key publically available, parts of the CI process would just have to be disabled.


The main problem is the CI code sits with the repository and thus can be changed by code changes in a forked pull request. This has all kinds of implications. A workaround is to have sensitive parts of the pipeline in a trusted context somehow. Jenkins does this with shared libraries and CircleCI does this with contexts (and maybe could do this with Orbs).


Actions seem to be a good candidate for this type of trusted context. Actions are run in isolated containers with defined inputs which reduces the attack surface area. Actions can be version-locked and maintained by trusted vendors or in a separate trusted repository. These trusted actions could be granted access to specific secrets (approved in Secrets admin settings). The execution context of actions could not be altered by pull requests from forked repositories. For forked pull requests, the workflow files of the base branch should be used (not the one from the forked branch). This prevents alterations of the CI in a forked pull request.


This would be very useful for 3rd party integrations where a secret key is required (Codecov, ChromaticQA, Cypress, etc). Actions could be created for all these that request access to encrypted key were the execution context is contained in the Action and cannot be altered by the pull request. It could look something like this:


  - uses: cypress-io/cypress-run-action@v1
      record-key: CYPRESS_RECORD_KEY # CYPRESS_RECORD_KEY is the name of the secret


The `cypress-io/cypress-run-action` would be given the `record-key` input as a decrypted key from the Secrets of the repository by name. Further security could involve an acceptance of `cypress-io/cypress-run-action` in the "Settings" admin tab for secret management (though if the workflow is only run with code from the target branch I'm not sure this is strictly necessary). The `cypress-io/cypress-run-action` would be a wrapper around the following command line:


npm run cypress:run -- --record --key=$INPUT_RECORD_KEY


2 Replies
Pilot Lvl 1
Message 2 of 3

Re: Allow secrets to be shared with trusted Actions

@NicholasBoll  Even I have put up this proposal in several discussion in this forum. I just also would like to add one point further to your proposal. It would be great  to have read/write permission for the GITHUB_TOKEN for the trusted GitHub Actions to the PR coming from the forked repository. 


This proposal is already discussed here and here

Copilot Lvl 3
Message 3 of 3

Re: Allow secrets to be shared with trusted Actions

@ibakshay Thanks for the reply and for the links (the first one didn't work for me, the second one did). I found a few of the linked issues, but not all in my searches. There is a lot of focus on the GITHUB_TOKEN being a read/write token. I think that should be added to the proposal. I think you should be able to opt-in to sharing a token with write access the same way you could opt-in to sharing secrets with actions.


I talked at length with a number of people about the possible attack vectors this proposal would open up. The primary risk to security is execution of code. A workflow has almost an unlimited execution context (you can run any command in a `run` step). An action (`-uses` step) has a very limited and predefined execution context. Security risks should be sufficiently minimized by trusting the execution context of an action and the inputs provided to the action.


Jenkins already does this with shared libraries - only an admin can add a shared library as a trusted execution context. Jenkins will run all code within the shared library outside the security sandbox it reserves for any code run in the `Jenkinsfile`. It seems like CircleCI could do the same thing with Orbs. They could be trusted execution contexts instead of just convenient wrappers around sharable parts of a CI pipeline.