Granular permissions for Container Registry

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

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 or foo:4.1, but not foo: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.