1780095 - Mozilla organization Mirror Action Approval or Recommendations!

Status: RESOLVED FIXED

(mozilla.org :: Github: Administration, task)

Description

[Brett Kochendorfer]

Hello,

Over in https://bugzilla.mozilla.org/show_bug.cgi?id=1778582 we requested access to a particular mirroring action so that we can keep things in sync with Gitlab. We have a couple repositories that live in the mozilla Github organization but mirror to the Gitlab mozmeao organization where we perform actions on them.

• https://github.com/mozilla/bedrock/
• https://github.com/mozilla/nucleus/
• https://github.com/mozilla/awebpodcast/
• https://github.com/mozilla/release-notes/

We could either enable the same action for this organization, fork it and enable it, or run something similar in shell. I don't think the later two would be very difficult I just worry about leaking passwords where as they've already figured that kind of stuff out in the actions.

Let me know what you think!

Regards,
Brett

Comment 1

[Chris Knowles [:cknowles]]

Per Hal's comments in bug 1778582 - I'm not approving this without secops eyes. NI'ing Hal and Austin.

Comment 2

[Brett Kochendorfer]

I was thinking about ways to mitigate risk here and reading through https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions.

The biggest risk I would be concerned about is having this action enabled in a repository and then having the credentials leaked through some PR which has access to the secrets. We can mitigate some risk by creating a Gitlab token for each mirror that has only read/write access to the corresponding repository in Gitlab for mirroring. Is there anyway to scope a secret so only a particular action has access or is it a free for all?

Comment 3

[Chris Knowles [:cknowles]]

per the docs on encrypted secrets in github here: https://docs.github.com/en/enterprise-cloud@latest/actions/security-guides/encrypted-secrets I'm seeing that "repo" appears to be the most granular "scope" of the secret. there is mention of "environments" but the references are all around deployments, and don't seem to have any controls tighter than "repo" from the docs I'm finding.

Comment 4

[Paul [:pmac] McLanahan]

Actions don't allow access to secrets when triggered via a pull-request:

Workflows triggered using the pull_request event have read-only permissions and have no access to secrets.

From https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#accessing-secrets

Comment 5

[hwine]

I'm a bit confused here, as I don't see where secrets-registered-in-GitHub come into play with GitLab integration:

• if secrets are compromised from a malicious PR on GitHub, that's independent of GitLab
• aiui, there are no secrets-registered-in-GitLab
• aiui, all secrets are accessible only the self-hosted runners in AWS, which are triggered by the GitLab workflow.

The mirror action is only going to mirror branches in the GitHub source repo, which only contains PRs opened by people who are already trusted with write access. So, there does not appear to be any escalation of privilege caused by GitLab triggering CI on any branch.

cknowles: okay to enable action for the mozilla org, the same as for mozmaeo

Comment 6

[Chris Knowles [:cknowles]]

action enabled in mozilla. I think that handles the actual main thrust of this bug - so I'm closing out - if I'm wrong, please reopen.

Comment 7

[Brett Kochendorfer]

Seems good. I just wanted to mention that the secrets we are talking about are the credentials for a "robot user" in GitLab to Push to GitLab from GitHub.