Add details on authentication / permissions used

See https://github.com/actions/upload-artifact/issues/197. I have an analogous question: I can create cache entries but I’ve (tried to) set the GitHub Token to read-only permissions. So, I’m puzzled as to why my jobs even succeed at writing to the cache. Is the cache action using an undocumented mechanism for authentication as https://github.com/actions/upload-artifact/issues/197 claims upload-artifact is? How can we control which jobs are allowed to read from and especially write to the cache?

[dhadka]

I pinged our security team to also get 👀 on this.

[dhadka]

@briansmith Great question.

Is the cache action using an undocumented mechanism for authentication as actions/upload-artifact#197 claims upload-artifact is?

Yes, it’s using the same mechanism as the artifact actions (see here).

I can create cache entries but I’ve (tried to) set the GitHub Token to read-only permissions. So, I’m puzzled as to why my jobs even succeed at writing to the cache

I’m not an expert in all of the details, but from what I understand, GITHUB_TOKEN is essentially used to authenticate with the GitHub API. So you can restrict Actions to have read-only permissions to your repos, issues, or other GitHub resources / products. But in this case, Artifacts and Cache are part of Actions, so those permissions don’t apply.

There isn’t a way to control which jobs are allowed to read/write to the cache, except by controlling where the cache is used in the workflow. This also means its important to be aware of when / how your workflows are run. Two good resources on this topic are:

1. https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions
2. https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

The cache has an additional safeguard called “scopes”. You can think of the scope as the git ref, such as a branch, tag, PR merge, etc. We then grant “read+write” or “read-only” permissions to each scope. For example, a workflow triggered on a branch will have “read+write” permissions to that branch scope and “read-only” permission to the default branch (e.g., main). This prevents a malicious user from being able to inject cache content on one branch that is subsequently used by a different, more critical branch (e.g., a release branch) without first merging those changes. For reference, the official docs for this are:

1. https://docs.github.com/en/actions/guides/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache.

Anyway, that’s about my breadth of knowledge on this topic. I’m happy to put you in touch with someone on the Actions security team if you have any additional security concerns.