The registry is fine for our use case, which is to manage all the dev artefacts on a private repo before CI might push a release to a production registry.
> any non-protected runner can push to it
My understanding is the job token inherits its permission set from the user causing the job to run. If the user has `write_registry` to a project (developer up), then the job does. Do you see more access than that?
The access can be limited per project to specific projects by setting a scope [0] but your description sounds like it might access within the project that is the issue.
0: https://gitlab.sam3.io/help/ci/jobs/ci_job_token#configure-t...
The whole point of having protected runners is to do things that developers are not allowed to do. If any developer can push images to the registry without any review/approval, and those images are used in other CI pipeline that's a problem for us.
Having a separate production registry is good indeed, but for images to be used for CI itself, having something self-contained within gitlab would have been nice.
The fact that any non-protected runner can push to it makes it useless to store images to be used in other CI pipeline (unless I missed something, which I would be really glad)