Building on the work from https://gerrit.wikimedia.org/r/q/Ibb26c5fc9 and https://gerrit.wikimedia.org/r/q/I63eb819db, can we add registry.gitlab.com/security-products/**/* as an allowed image registry? registry.gitlab.com/gitlab-org/**/* already exists, but excludes the security-products path, which the Security-Team would at least like to make available, so that folks can use Gitlab's limited, though free SAST CI options AND free secret-detection template.
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add registry.gitlab.com/security-products/**/* as allowed images | operations/puppet | production | +1 -0 |
Related Objects
Related Objects
- Mentioned In
- T320730: Define access to external resources for GitLab CI Runners
Blog Post: Application Security Pipeline in Gitlab: A Journey! - Mentioned Here
- T320730: Define access to external resources for GitLab CI Runners
T291978: Limit GitLab shared runners to images from Wikimedia Docker registry
Event Timeline
Comment Actions
Change 838194 had a related patch set uploaded (by SBassett; author: SBassett):
[operations/puppet@production] Add registry.gitlab.com/security-products/**/* as allowed images
Comment Actions
To me it's not clear what images are in registry.gitlab.com/security-products/**/* . The group in gitlab.com has multiple projects and groups: https://gitlab.com/gitlab-org/security-products. I was unable to query the registry for all available images. So I have some concerns allowing everything from the group, including all new projects.
I would be more comfortable with allowing only the needed security scanners.
We can also think about two separate allowed_images lists for WMCS Shared Runners and the Trusted Runners. For the Shared Runners I have less concerns allowing registry.gitlab.com/security-products/**/*.
If you find a way to query the registry for all available images that would help too.
My concerns are also relevant for registry.gitlab.com/gitlab-org/**/* after thinking more about that topic.
Comment Actions
Ok. I had thought the plan was to be a bit more flexible about the allowed images for certain gitlab runners, per the extensive discussions in T291978. It sounds like this is no longer the case? From the discussions there, it seems like other FOSS orgs like KDE are apparently ok with allow-listing various gitlab.com images. I would think there might be a bit more trust there than say some random docker hub image. Should we file some kind of upstream bug with gitlab.com to allow for more visibility into their CI image registries?
I would be more comfortable with allowing only the needed security scanners.
The problem is that we don't really know this at this time. And a very likely answer might be *all*.
Comment Actions
it seems like other FOSS orgs like KDE are apparently ok with allow-listing various gitlab.com images
And that is also what Jelto is suggesting. Allow-listing sounds to me exactly like a list of allowed images, but not a "anything" wildcard.
The problem is that we don't really know this at this time. And a very likely answer might be *all*.
In the ticket description you give very specific reasons why you want to allow it ("Gitlab's limited, though free SAST CI options AND free secret-detection template.") and on https://docs.gitlab.com/ee/user/application_security/sast/ I see a specific list of images.
It seems to me that is already the needed information.
Comment Actions
My concerns are also relevant for registry.gitlab.com/gitlab-org/**/* after thinking more about that topic.
We already use wildcards to allow everything under a set of specific Docker Hub namespaces: centos, debian, fedora, opensuse, ubuntu, python, ruby, and rust. In addition to everything in registry.gitlab.com/gitlab-org/**/*.
It doesn't seem like the registry.gitlab.com/security-products namespace is conceptually different in a way that should require enumerating every specific allowed image, unless we really want to do the same for all of those other providers?
Comment Actions
I agree, the requested registry is not a lot different from what we already do with gitlab-org namespace and some Dockerhub namespaces. But at least for the Dockerhub ones it's known what images are available. For gitlab-org and the new security-products I was not able to aggregate what images we are allowing here. If you have any idea of aggregating a list I would be happy. But the api/_catalog endpoint needs authorization.
So that increased my concern of adding more and more sources were we don't know what we actually allow.
I opened up T320730 to have a general discussion about what direction we want to take of allowing external/3rd party resources. Sorry if that blew up this quite reasonable and small request here. But I'd like to have some clarity or policy of what we allow first. In general I like the idea to have easy access to security tools in CI jobs.
Comment Actions
+1. There are definitely levels of implicit trust which are traded off with convenience and functionality.
Comment Actions
Change 838194 merged by Jelto:
[operations/puppet@production] Add registry.gitlab.com/security-products/**/* as allowed images
Comment Actions
registry.gitlab.com/security-products/**/* images are available on Shared Runners now. We discussed this external security scanners don't need Trusted Runners. Running this security products on Shared Runners should be fine for most use cases.
I'm closing this task. Feel free to re-open if anything is missing.