1949247 - Assess allowing public container images for MozillaSecurity

Status: RESOLVED FIXED

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

Description

[Dennis Schubert [:denschub]]

We have a public repo at MozillaSecurity/WebCompatManager, which is using GitHub Actions to build a container image. Pushing the container image works, and it's available privately here. I can't set it to public, the public visiblity "Setting is disabled by organization administrators".

Given the repo is public, I don't immediately see a reason why the built image should not also be. It would make deploying easier, as we didn't need to wrangle with a GitHub token. Filing this to investigate making this public.

Comment 1

[Chris Knowles [:cknowles]]

Secops generated a list of recommended settings for orgs - and "only private packages" is a) what they recommend, and b) the GitHub default.

afaik, this is the first time this has been asked - so we're probably "winging it" at some level here.

Pushing this at Clovis Foji to review and ask questions.

Comment 2

[Dennis Schubert [:denschub]]

Note, the image is currently pushed to Docker Hub (we're trying to switch away from that because we WebCompat folks don't have write access there), and that image is public: https://hub.docker.com/r/mozillasecurity/webcompatmanager

Comment 3

[Clovis Foji]

@dennis,

This is the first time i am coming across this request so i need to understand some few things.

1. I can't access https://github.com/MozillaSecurity/WebCompatManager/pkgs/container/webcompatmanagerto see the content. Do you guys store any other packages in here apart from the docker images? The image is already public in Docker Hub so making it public in github won't introduce any other security risk but we do not want to accidentally exposed other packages which in the directory which are meant to be private.

Comment 4

[Dennis Schubert [:denschub]]

It's just the Docker image as far as I know. ni? truber to confirm there is nothign else on https://github.com/orgs/MozillaSecurity/packages that I don't see.

Comment 5

[Jesse Schwartzentruber (:truber)]

I also don't see anything there except the webcompat docker image.

Comment 6

[Clovis Foji]

With this being an Org wide setting, i will have to do some more security risk analysis.

Comment 7

[Chris Knowles [:cknowles]]

Sorry - let me be clear. This would involve changing the org settings for the mozillasecurity org to allow ANY repo to publish public packages - NOT just making this one package public.

I don't think that's a problem, I just want to make sure we're all on board with that being the change.

Clovis, if you could re-affirm.

Comment 8

[Jesse Schwartzentruber (:truber)]

(In reply to Chris Knowles [:cknowles] from comment #7)

Sorry - let me be clear. This would involve changing the org settings for the mozillasecurity org to allow ANY repo to publish public packages - NOT just making this one package public.

I don't think that's a problem, I just want to make sure we're all on board with that being the change.

I'm not familiar with this service of GitHub, but if we're talking about Docker images, I don't see any problem. We assume all Docker images are public.

Comment 9

[Chris Knowles [:cknowles]]

Sure, but GitHub treats these under the packages model, and changing that is an org wide change, so security needs to review - as I said, I don't think that's a problem. Unfortunately a lot of GitHub's settings are pretty broad, so there's potential for unintended consequences - if there were a way to open this for this repo only, that would be a much easier shift.

I've slacked with Clovis, he's looking at this. Barring any news from him before then, I'll be sure to mention this in our GHE team meeting tomorrow.

Comment 10

[Dennis Schubert [:denschub]]

Unfortunately a lot of GitHub's settings are pretty broad, so there's potential for unintended consequences

JFTR, for my own curiosity, I tested this in a GHE I am admin in, and flipping the setting does not seem to touch the visibility for existing private packages. Also, newly created packages from private repos are private by default and you have to manually toggle them to public, regardless of the availability of that visibility setting.

Comment 11

[Chris Knowles [:cknowles]]

I wouldn't think it would affect the visibility of existing packages. Given that they're already out there - you wouldn't want to flip the visibility willy-nilly for an entire org.

But I also confirmed that changing the org setting for packages to allow public will allow the visibility change to public, and should allow creation of public, if the package type allows that per GitHub - I think that the current situation is driven by the fact that the org setting is for private packages only. The Repo visibility should (if I'm reading the manual right) drive the package visibility - unless the org setting is more restrictive.

The only other org level setting appears to be "Inherit access from source repository" - which is currently set to true. With Clovis' blessing, happy to experiment there as well. (As I mentioned, this is the first effort to change the package settings.)

Barring an early morning email, I'm making sure that this is on the agenda for the GHE team meeting on Tuesday.

Comment 12

[Clovis Foji]

Given some additional research and reviewing of Github documentation, i am approving this request.
https://docs.github.com/en/packages/learn-github-packages/about-permissions-for-github-packages#granular-permissions-for-userorganization-scoped-packages

Comment 13

[Chris Knowles [:cknowles]]

Alright - I've clicked the buttons to allow public packages in the org, and verified that the visibility switch should now allow for public packages.

Let us know if there are other settings you'd like to look at.

Comment 14

[Chris Knowles [:cknowles]]

Based on lack of noted concern - closing this out. If you need anything more, don't hesitate to reach out or reopen as appropriate.