4

I want to be able to let the users push a docker file along with code to gitlab and let the gitlab build the image, that can then be pulled by authenticated user of the project.

The problem is , I want to make sure the users dont push docker images directly to gitlab container registry , so that we can review the docker-files and control , and make sure the Dockefiles are using the Redhat only registry to pull stuff from.

How can we prevent users from pushing thier own built image to gitlab? In other words , how can we make sure that docker image in the container registry of gitlab project is the one built by gitlab from dockerfile and is not the one pushed by the project users direclty from somewhere else?

Ijaz Ahmad
  • 11,198
  • 9
  • 53
  • 73

2 Answers2

2

I don't think it's currently possible. If you check gitlab's permissions model, you'll see that the user access levels determine what you can do in the container registry:

  • read rights are available as Reporter+
  • update rights are available as Developer+

If your users are developers, then they will be able to push images to the registry. If you want to limit that to gitlab-ci builds, you'd need to use protected branches and limit your users to Reporter access level (probably not what you want).

An alternative a bit convoluted would be to setup a second project that is used as the source for images, and configure its build setup to pull from the first project protected branch. Commits to the protected branch in the first project would always have to be reviewed and docker images would be pulled from the second project.

dlouzan
  • 675
  • 7
  • 16
  • Thnaks , we have shifted our docker registry from gitlab to docker trusted registry , and now I am thinking the same kind of access for that. OR we will just allow push from everywhere but require the image to pass all the security scans in order to be signed and deployed – Ijaz Ahmad Oct 29 '18 at 17:34
2

deploy tokens is probably the best way forward. You can grant these on a per-repository or a group basis and specify granular access such as, for your use case read_registry as well as an optional expiry date.

Another option is to use personal access tokens. These are set globally for a user and you can specify as many as you like (eg one for each client), set an expiry date, and restrict access to read_registry.

bighairdave
  • 592
  • 5
  • 19