Granular permissions for Container Registry
Description
The container registry allows full control of all images for all developers on a project. Teams need to both extend and restrict control more than that.
Some use cases:
-
Expose (some) images to the public, without exposing anything else (code repo, CI/CD pipelines, job logs, etc.). E.g. let anyone pull
foo:latest
orfoo:4.1
, but notfoo:long-commit-sha
-
Restrict (some) tags to operator or admin users only. e.g. let users specify patterns to protect, similar to protected branches.
-
Let developers push to otherwise protected image tags iff the right right hurdles have been cleared (e.g. a MR is approved and CI/CD has passed). (This might be a harder than you'd think, as the registry is unaware of where a push is coming from.)
-
Promote a temporary CI image to a named image (thus turning a developer-generated image into a protected image). This should automatically be covered by the above, but calling it out so we don't forget that a single image may have multiple tags and we should think about restricting the tag, not the image itself.
-
Read-only tokens for use in deployments (e.g. for Kubernetes to pull the image as needed)
--
Original description:
Today I saw a developer can delete images in the container registry, which might be a problem.
This is only one case, there are more, but we might need a better permission system, maybe with protected containers etc.