Using these features one can protect every aspect of the release process, except the actual result (container or package). This means any developer of the project can:
Delete a container or package that was created by a protected release process.
Overwrite a container or package that was created by a protected release process.
Intended users
Devon (DevOps Engineer) will restrict the access to container registries and package repositories as part of implementing a secure CI/CD approach.
Sam (Security Analyst) will validate that the access to container registries and package repositories was restricted to verify that the CI/CD approach was implemented securely.
The configuration options can be put under Project Settings -> General -> Visibility, project features, permissions ->
Container registry
Packages
A control can be put next to the checkbox. Similar to the other controls in this section.
Out of Scope
This issue is about protected repositories, not protected tags. Support for tag immutability is being tracked at container-registry#82 (closed).
Permissions and Security
This change would align the ability to configure permission settings for container registries and package repositories with the existing approach to protected assets.
What does success look like, and how can we measure that?
Container registries and package repositories can be properly protected.
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
@dosuken123 I'm wondering if we can actually enforce security on all the accesses to the registry, since it is accessible directly, without changing the registry code (that is mostly out-of-the-box).
To update current possibilities: we can limit the access to repository, not tag. In future, if we implement the more integrated approach, we could also limit access to tags. Today, the low-hanging fruit is access to sub-repositories of images.
someone could push to an image (that otherwise would have been generated from a protected branch) using their regular login
That's also my concern. In my setup, every branch and tag uses gitlab ci to build docker images which it pushes to the gitlab registry. These images are used for tests and review apps, but also for the production environment. Currently, any user can push an image corresponding to a protected branch or tag. This means that anyone with developer access can override an image pushed by the pipeline of a protected branch/tag that's meant to be used in production.
Today, the low-hanging fruit is access to sub-repositories of images.
If I understand what this means, it would actually work great! Are you referring to the 3 levels of image names supported per project? If so, I'm already using this to separate production/protected images from temporary/unprotected/test/review-app because it allows me to periodically purge the latter group of images to keep registry size small.
We're having the same concern in the Security-Products team. Our images are used on production, and need to be protected:
Almost everyone at GitLab can push to existing images and tags, which is a serious security issue
One can override an existing tag when testing, by pushing a image without a specific tag. In this case, Docker will push all local tags, and override existing ones on the registry, even if they are most recent.
+1 for this. I think we need a way to protect certain images. Since someone can easily delete image from registry and break things for many users. cc @bikebilly
@dzaporozhets@plafoucriere we can define "protected images", defining a pattern for image:tag: if it matches, the image is protected.
Which are the limitations on protected images? Only a specific set of roles can push/delete, while anyone (according to the actual security model) can pull. Is this enough?
the "power user" may be people with Master privileges, or people that can merge/push on protected branches. I'm not sure which is the information that is accessible from the registry authentication context, what do you think @ayufan?
I am just looking at Gitlab right now and protected images is exactly what I need. We have a branch->master model, but obviously I'd like to keep regular developers from being able to overwrite CI produced tags in project container registry. I can workaround this with tokens, but if Gitlab enforced it then it'd be a lot easier.
@dcroft Protected images/tags are definitely of interest, but lower on the priority list for the Container Registry. Our immediate priorities for the Container Registry are:
We are currently running performance tests and benchmarks and coming up with a plan for the best way to do that.
Then we will focus on improving S3 then GCS
Persist data to power reporting, metrics and an improved UI. Moving at least the Docker metadata to a database is a key first step to quotas and limits.
In addition, we are working on adding expiration and retention policies. In the upcoming milestone, we'll add this MVC, which will add image expiration policies for all new projects.
Introduce quotas and limits for projects/groups (This has been pretty stale for the Container Registry, but once we figure out the above, we can move forward.
Is there currently a way to protect against anyone publishing to a tag (or publishing at all) in a registry, or is that what this story is centered around? The security concerns without this feature makes me a little hesitant about implementing publishing to the gitlab registry for production use.
Thank you! Definitely really interested in this feature since allowing Developers through Owners to delete production level packages is a security concern of ours.
We have containers that are pulled on the fly from the same production tag (which came from a deploy from trunk). This happens during job-time to ensure it always has the latest version of the container.
We also have users who are developers in the project to encourage contributions from people other than the direct code owners of the project. Unfortunately, this means that the developers can override the production tag at any point and wreck havoc on all on-the-fly docker pulls.
Could really use this for pulls of up to 16,500 per day.
This has been identified as a high-priority desire to mitigate the risk of unintentional breakage of many pipelines/builds for a 5,000 seat Silver .COM customer.
@trizzi I think that would already solve most cases.
However, from what I understand the access token of a job is based on the permissions of the user that is considered to trigger that job (based on commits?).
Would this pose a problem with restricting rights? For example, would this work?:
Container management is restricted to maintainers.
A job is considered to be triggered by a member who is a developer.
The job needs to publish a container.
Because you want to be able to restrict the developer from being able to delete / manually publish containers, but not restrict the pipelines at the same time.
Note: the pipelines can already be protected by getting the .gitlab-ci.yaml to a separate project.
@marqlagendijk I think that would pose a problem. If we followed the model for protected branches, the user running that pipeline would need the ability to publish that container. Do you think you could use deploy tokens for this purpose? (Assuming they had the ability to write to the container registry?
@trizzi checking in here, looking to protect docker registry tags, so that production containers don’t get overwritten by accident. Are you confident in 13.1 for this?
Why interested: restrictions are too lax at the moment allowing any developer to remove release / production grade image
Current solution: using external Container Registry (OSS Nexus), where release-grade images are stored, GitLab Container Registry is used to store all development images
Considered as very important for Package and Release stage adoption
@trizzi - we had a call with one of @dzalbo customer's and they would like to move from Nexus (now that we offer the Generic Package Registry), but can only do it if we can protect these.
Thanks for the ping! It might be worth calling attention to this issue: #292129 (closed), which proposes adding a type attribute to generic packages. This is relevant because it's possible we can add a protected attribute as well.
Timing-wise, I expect we will try to get to this sometime in March for packages. The container registry will be a bit later because it's dependent on &2313 (closed).
we are an Enterprise Customer and really need the Feature to protect released images in our container registry.
Are there any news/updates if this will be implemented?
This issue is currently a securityfeature, meaning the PM has to prioritize the issue. This feature would help us internally quite a bit so I would love to see this landing in the product sooner rather than later. Applying internal customer to document that we want to use this feature internally.
Thanks for the feedback and it's an interesting point. This is definitely something we want/need to tackle in the coming milestones. Once we release and migrate to registry v3, which includes some significant changes, we'll unblock this work.
That's a cool idea and an interesting way to bring together the container scanning feature and the registry, something @icamacho and I are starting to think about now in #37141 (closed). Once we have a design for this, it would be great to review it with you.
It also reminds me of an issue #195486, which proposes adding labels (tags) for packages.
Would this also apply to Maven packages? Can we assume tags will be generated via CI? Are compliance-related tags most important?
I think tags might be more related to #18264, which is probably needed for long term security.
The primary reason this issue is important to me is our cloud system uses <docker_image>:latest when spinning up new instances. Currently any developer can just push their own custom :latest and our system would start using it if we used GitLab's registry.
We are working around the issue by using AWS ECR and protected variables instead, but it's a hack and I am sure that there are still vulnerabilities lurking in our, admittedly quick and dirty, implementation.
As a Premium User this is a show stopper to actually use the Registry for other then as testing/CI maybe.
Hacking it with pushing to another registry from the CI (where all the components are present from which the image can be built) would be a bad hack with extra maintenance.
Should this be split out into a couple/few epics each of which focus around one aspect of the package/container repository that GitLab provides. One for containers, One for Maven, etc.
On a different note for container protections is there a way to marry them to a protected tag/environment/branch so they cannot be updated or pulled outside of that protection
Good idea @joseph3262, I've been meaning to do exactly that. I'll keep this issue focused on the container registry and open new ones for each package manager format all rolled up in an epic.
Sorry for not closing the loop on this. Here is the epic for the Package registry that breaks out each individual package manager format and proposes adding the concept of protected packages. &5574.
Tim Rizzichanged title from Identify images and packages as protected to prevent accidental deletion/updates to Identify container images as protected to prevent accidental deletion/updates
changed title from Identify images and packages as protected to prevent accidental deletion/updates to Identify container images as protected to prevent accidental deletion/updates
Tim Rizzichanged the descriptionCompare with previous version
There is a LargePremium customer interested in this issue and the related epic #878. This customer is interested in preventing users with the Developer role the ability to delete images in Container Registry. GitLab team members with access to ZenDesk can learn more in the ticket.
We've also reported this before via the security mailing list, as developers can retrieve all protected variables and modify running production code if the Docker image in the registry is used to deploy (which is often the case for us).
I also think that it seems like a basic feature and should be in the Free tier already, similar Protected Branches and Protected Tags.
Link to request: GitLab team members may click the linked mention to view additional detail for this request within the customer's collaboration project.
We are using self-managed Gitlab instance with Ultimate license. It's really a challenging for us to maintaining container registries without these feature. Please expedite and help us to get this soon. Thanks.
A premium customer has raised this as a high priority item for them. They have had a case where a tag was accidentally deleted along with a critical container image. /cc @trizzi
João Pereirachanged title from Identify container images as protected to prevent accidental deletion/updates to Allow protecting container repositories against writes
changed title from Identify container images as protected to prevent accidental deletion/updates to Allow protecting container repositories against writes
João Pereirachanged the descriptionCompare with previous version
changed the description
🤖 GitLab Bot 🤖changed the descriptionCompare with previous version
I've updated this issue to focus on protecting container repositories against writes. Individual tag protection is being tracked as a separate feature in container-registry#82 (closed).
Why interested: "We want [an image] to be built only once via a pipeline, from a Git Tag, published only once and then there’s zero risk of a malicious actor replacing a trusted image with an untrusted one."
Current solution for this problem: None
Impact to the customer of not having this: Worried about problems arising from Developer-level project members being able to overwrite existing images from outside CI/CD
Why interested: Basically the same as the customer from this earlier comment:
We want [an image] to be built only once via a pipeline, from a Git Tag, published only once and then there’s zero risk of a malicious actor replacing a trusted image with an untrusted one.
Current solution for this problem: None
Impact to the customer of not having this: Images can be overwritten and there's risk of a trusted image being replaced by a non-trusted image.
As of the moment it seems as if anyone in our org that has an access token can publish to our package repository and we'd like to lock that down to only pipelines being able to publish there.
Furthermore, I would like to start the discussion regarding e.g. concept, implementation plan, performance, etc. Based on the discussion with @10io and @trizzi, I propose to start with the following scope and implementation approach:
v1.0 - Basic PUSH protection for container repository based on container_repository_name
Build / Introduce feature flag for development => separate MR
Add model for ContainerRepositoryProtectionRule => separate MR
Integrate basic CRUD operations for ContainerRepositoryProtectionRule via GraphQL API => separate MR
Evaluation of ContainerRepositoryProtectionRules based on container_repository_name (with wildcard pattern) and integration in auth flow of container registry following the POC !123546 (closed) => separate MR
I hope this proposed scope hits the core of this issue. Of course, further iterations and other small functions are necessary to flesh out this feature, e.g. UI frontend for ContainerRepositoryProtectionRule, REST API, DELETE protection, etc.
@trizzi@10io FYI: I will prioritize and move forward with the package protection in the order stay focussed on this. However, working on this POC helped me to understand the similarities in scope and implementation between the package and container protection feature that we need at Siemens.
@gerardo-navarro, thanks for this! I see this is linked to &9825, but this is actually an older issue that I didn't notice at the time that we proposed the changes described in &9825. So, to keep things simple and organized, I'd propose the following:
Close this issue in favour of &9825. I think it's worth to keep this issue unchanged (instead of promoting it to an epic and update the description to replace &9825) as this is very old and there is a lot of valuable context in here.
As described in &9825, the easiest first step is to tackle the protection against deletions (one of the planned write protections). There is already an issue for this: Protected containers: Delete protection (#406797), which describes a proposed implementation plan. Could you look at it and share your thoughts/proposals there?
Fine by me. I will continue the discussion in &9825 .
There is already an issue for this: Protected containers: Delete protection (#406797), which describes a proposed implementation plan. Could you look at it and share your thoughts/proposals there?
I am totally fine with continuing the discussion in this other issue. I will take a look and share my thoughts.