This is a proposal to solve a problem related to https://github.community/t5/GitHub-Actions/Make-secrets-available-to-builds-of-forks/m-p/30678
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 vectors of execution context. 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, autolabler, etc). It could look something like this:
steps: - uses: cypress-io/cypress-run-action@v1 withSecret: record-key: CYPRESS_RECORD_KEY # CYPRESS_RECORD_KEY is the name of the secret
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
If each action is run in an isolated container with the workspace being the only shared context, this should be a safe operation. Another action could not leave a process running or modify $PATH to capture keys. Running the action from the base branch for forked repos ensure a forked workflow script could not alter execution.
I see this proposal as very similar to the way Github Apps are treated.