Give Docker image registry its own HTTPS certificate - not bundled with rest

Currently I have three environments Test, Stage and Prod with GitLab-CE 13.5 (I know it’s old, the contractor is working on it), gitlab-runner:ubuntu-v13.7.0 and the Docker image registry:2.7.1. For Test and Stage I do the TLS/HTTPS termination myself and can include the public and private key. All good. But: For Prod, another colleague does the TLS/HTTPS termination. This means that I do not have access to the private key. I can’t change that in the near future. Is it possible to equip the Docker image registry with a different, separate URL with an HTTPS certificate and integrate it in GitLab and in the Docker image registry, or is there a show stopper?

docker-compose.yml

version: '3'

services:

    gitlab:
        environment:
            GITLAB_OMNIBUS_CONFIG: |
                external_url '***'  # kein Gleichheitszeichen "="!
                registry_external_url = '***'

                gitlab_rails['env'] = {
                    "http_proxy" => "***coporate-proxy***",
                    "https_proxy" => "***coporate-proxy***",
                    "no_proxy" => "127.0.0.1,localhost,***"
                }
                # Needed for proxying Git clones:
                gitaly['env'] = {
                    "http_proxy" => "***coporate-proxy***",
                    "https_proxy" => "***coporate-proxy***",
                    "no_proxy" => "127.0.0.1,localhost,***"
                }
                gitlab_workhorse['env'] = {
                    "http_proxy" => "***coporate-proxy***",
                    "https_proxy" => "***coporate-proxy***",
                    "no_proxy" => "127.0.0.1,localhost,***"
                }
                gitlab_pages['env'] = {
                    "http_proxy" => "***coporate-proxy***",
                    "https_proxy" => "***coporate-proxy***",
                    "no_proxy" => "127.0.0.1,localhost,***"
                }
                # If you use the docker registry:
                registry['env'] = {
                    "http_proxy" => "***coporate-proxy***",
                    "https_proxy" => "***coporate-proxy***",
                    "no_proxy" => "127.0.0.1,localhost,***"
                }

                gitlab_rails['gitlab_shell_ssh_port'] = ***
                nginx['listen_port'] = 80
                nginx['listen_https'] = false
                nginx['hsts_max_age'] = 0
                nginx['hsts_include_subdomains'] = false
                gitlab_rails['gitlab_email_from'] = '***'
                gitlab_rails['gitlab_email_display_name'] = '***'
                gitlab_rails['gitlab_email_reply_to'] = '***'
                gitlab_rails['smtp_enable'] = true
                gitlab_rails['smtp_address'] = '***'
                gitlab_rails['smtp_port'] = ***
                # gitlab_rails['smtp_user_name'] = '***'
                # gitlab_rails['smtp_password'] = '***'
                gitlab_rails['smtp_domain'] = '***'
                # gitlab_rails['smtp_authentication'] = ***  # Fehler: ArgumentError (wrong authentication type false)
                gitlab_rails['smtp_enable_starttls_auto'] = ***
                gitlab_rails['smtp_tls'] = ***
                gitlab_rails['smtp_openssl_verify_mode'] = '***'
                # Docker-Image-Registry:
                gitlab_rails['registry_enabled'] = true
                gitlab_rails['registry_api_url'] = '***'
                gitlab_rails['registry_host'] = '***'
                gitlab_rails['registry_port'] = 443
                # gitlab_rails['registry_issuer'] = '?'
                gitlab_rails['registry_key_path'] = '/certs/registry.key'  # !?
                # gitlab_rails['internal_key'] = '?'
        # extra_hosts:
			# ...
        hostname: '***'
        image: '***some-gitlab***'
        networks:
            - blubbi
        ports:
            - '***:80'
            - '***:22'
        restart: unless-stopped
        volumes:
            - './certs/:/certs/'
            - '/etc/localtime:/etc/localtime:ro'
            - '/etc/timezone:/etc/timezone:ro'
            - './gitlab/etc:/etc/gitlab'
            - './gitlab/data:/var/opt/gitlab'
            - './gitlab/logs:/var/log/gitlab'

    gitlab-runner:
        depends_on:
            - gitlab
        environment:
            - http_proxy=***coporate-proxy***
            - https_proxy=***coporate-proxy***
            - no_proxy=127.0.0.1,localhost,***
        # extra_hosts:
			# ...
        image: gitlab/gitlab-runner:ubuntu-v13.7.0
        networks:
            - blubbi
        privileged: true
        restart: unless-stopped
        volumes:
            - '/etc/localtime:/etc/localtime:ro'
            - '/etc/timezone:/etc/timezone:ro'
            - './gitlab_runner/etc:/etc/gitlab-runner'
            - '/var/run/docker.sock:/var/run/docker.sock'

    image-registry:
        environment:
            - http_proxy=***coporate-proxy***
            - https_proxy=***coporate-proxy***
            - no_proxy=127.0.0.1,localhost,***
            - REGISTRY_AUTH_TOKEN_REALM=https://***/jwt/auth
            - REGISTRY_AUTH_TOKEN_SERVICE=container_registry
            - REGISTRY_AUTH_TOKEN_ISSUER=gitlab-issuer
            - REGISTRY_AUTH_TOKEN_ROOTCERTBUNDLE=/certs/crt.crt  # !?
            - REGISTRY_LOG_LEVEL=warn
            - REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io
            - REGISTRY_STORAGE_DELETE_ENABLED=true
            - REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/registry
        # extra_hosts:
			# ...
        image: registry:2.7.1
        networks:
            blubbi:
        ports:
            - "***:5000"
        restart: unless-stopped
        volumes:
            - './certs/:/certs/'
            - './image_registry/shared/registry:/registry/'

    rest-api:
        environment:
            http_proxy: '***coporate-proxy***'
            https_proxy: '***coporate-proxy***'
            no_proxy: '127.0.0.1,localhost,***'
            HTTP_PROXY: '***coporate-proxy***'
            HTTPS_PROXY: '***coporate-proxy***'
            NO_PROXY: '127.0.0.1,localhost,***'
            JAVA_OPTS: '***'
			# ...
        # extra_hosts:
			# ...
        hostname: ***
        image: ***some-other-container***
        networks:
            - blubbi
        ports:
            - '***:8080'
        restart: unless-stopped
        # volumes:
            # - ...

networks:
    blubbi:

Do I understand correctly that I have to specify the CRT certificate (REGISTRY_AUTH_TOKEN_ROOTCERTBUNDLE) for the URL pointing to GitLab in the Docker image registry section (REGISTRY_AUTH_TOKEN_REALM)? And on the GitLab side/section, the private key to the same certificate must be provided (gitlab_rails['registry_key_path']) (which I don’t have and won’t get)? I am concerned that it says ROOTCERTBUNDLE. So does everything have to be available in ONE bundle certificate, or can one also give the Docker image registry its own certificate and bind it (together with the GitLab runners) to GitLab? Sorry I haven’t tried it out completely myself. I am a bit pressed for time, briefly on holiday and have not yet fully understood this interaction of GitLab components.

Hi @Dhumala
I am sorry, but could you describe your use-case a little as I am not sure what are you trying to achieve.
GitLab comes with internal container registry which is configured using the registry_ parameters.
Are you trying to replace the bult-in service with a custom one?

EDIT:
I assume you are trying to use your own Docker registry service and use GitLab for authentication.
In that case the gitlab_rails['registry_key_path'] has nothing to do with HTTPS certificates that are used for HTTP communication. You can read more about the setup here use-an-external-container-registry-with-gitlab-as-an-auth-endpoint

First of all, I am a colleague of Mr Dhumala. We work together.

We use the CE version. The text in your first paragraph refers to a feature of the EE version, which we do not have.

Correct. Your description and the text in the GitLab help now sound to me like I don’t need to specify the private key of the GitLab instance itself anywhere in my config. Is that the case? If so, that is exactly the answer to my question at the beginning and I am satisfied.

We will report the (mis)success.

Thank you very much.

Translated with www.DeepL.com/Translator (free version)