## Problem Right now there is no way we can protect image repositories against changes, either intentional or accidental. ## Solution Allow toggling **protection** against **deletes**, **pushes**, and/or **pulls** for individual image **repositories** within a project. Note that this is about the repositories, not the individual images/tags within. So this is not the same as https://gitlab.com/gitlab-org/container-registry/-/issues/82+. This applies to *all* images within a repository, and the repository itself. ### Target Users Only users that have owner or maintainer access to a given project should be able to configure this feature for image repositories within that project. ### Protections * **Delete protection**: To allow protection against intentional (but unwanted by owners) or accidental deletion of image repositories (and all images within as consequence). This can be useful when e.g. a repository contains release/deployment images and none of them should be deleted. * **Push protection**: To allow protection against adding any more images to an image repository. This can be useful to e.g. archive an image repository when used in conjunction with the delete protection. * **Pull protection**: To allow protection against downloading images from an image repository. This can be useful to e.g. make sure that images with sensitive data can't be pulled by anyone, either temporarily (such as when a security breach was detected and pulls should be temporarily disallowed during the investigation) or to archive them and make all images inaccessible for an undetermined period when used in conjunction with the delete and push protections. It should be possible to combine any of these three protections at will for maximum flexibility. This feature will also act as a catalyst for individual image protection policies (https://gitlab.com/gitlab-org/container-registry/-/issues/82), which would be the next logical step. ### Implementation * Add new attributes to each image repository on the Rails side (`container_repositories` table) to denote when a given repository is locked against deletes, pushes, or pulls; * Allow project owners/maintainers to toggle these settings in the UI, for each individual image repository within that project; * When a user requests a JWT token to allow them to pull/push/delete against a given image repository, Rails should check if the corresponding repository is locked against the wanted operation and refuse the request if so, effectively protecting the repository and all images within. As a caveat, we should make it clear that changes to these policies will take up to `N` minutes to come into effect, where `N` is the [configured JWT token expiry](https://docs.gitlab.com/ee/administration/packages/container_registry.html#increase-token-duration).