Re: Help using ImageStreams, DCs and ImagePullSecrets templates with a GitLab private registry (v3.6)

[Graham Dumpleton]

You are possibly hitting a bug with oc where it was generating the dockerconfig 
json in wrong format in 3.7.

If you used 3.6 oc client with 3.7 backend just when creating the secret it 
will work, if this is the issue I am thinking of.

If want confirmation, perhaps try with a 3.6 client.

Graham

> On 10 Apr 2018, at 7:45 am, Alan Christie  
> wrote:
> 
> Ah ha!
> 
> OK, the first approach did not work but your second suggestion worked!! Phew, 
> thanks … although I had to remove the “-w0" argument (they’re not recognised 
> on OSX). So the following allowed me to pull from gitlab: -
> 
> oc create -f - < apiVersion: v1
> kind: Secret
> metadata:
>   name: pullsecret
> type: kubernetes.io/dockerconfigjson 
> data:
>   .dockerconfigjson: $(echo -n "{\"auths\":{\"registry.gitlab.com 
> \":{\"auth\":\"`echo -n 
> "$GITLAB_USER:$GITLAB_PASSWORD" | base64`\"}}}"|base64)
> EOF
> 
> Thank you.
> 
> I am still intrigued to know why my previous secret (which works with 3.6) 
> does not work and in 3.7 I have to resort to this new approach.
> 
> Alan.
> 
>> On 9 Apr 2018, at 21:29, Pavel Gashev > > wrote:
>> 
>> Alan,
>>  
>> Just try the following:
>>  
>> # docker login registry.gitlab.com 
>> # oc create secret generic --from-file=.dockerconfigjson=.docker/config.json 
>> --type=kubernetes.io/dockerconfigjson 
>>  pullsecret
>>  
>> another way:
>>  
>> # GITLAB_USER=user
>> # GITLAB_PASSWORD=password
>> # oc create -f - <> apiVersion: v1
>> kind: Secret
>> metadata:
>>   name: pullsecret
>> type: kubernetes.io/dockerconfigjson 
>> data:
>>   .dockerconfigjson: $(echo -n "{\"auths\":{\"registry.gitlab.com 
>> \":{\"auth\":\"`echo -n 
>> "$GITLAB_USER:$GITLAB_PASSWORD" | base64 -w0`\"}}}"|base64 -w0)
>> EOF
>>  
>> From: > > on behalf of Alan 
>> Christie > >
>> Date: Monday, 9 April 2018 at 01:57
>> To: Gaurav P >
>> Cc: users > >
>> Subject: Re: Help using ImageStreams, DCs and ImagePullSecrets templates 
>> with a GitLab private registry (v3.6)
>>  
>> Sorry Guys, but I’m getting nowhere here. 
>>  
>> A long time has passed and I have been doing other things but keep returning 
>> to this and trying every single combination of URL that I can but nothing is 
>> working for me with GitLab.
>>  
>> The good news is that I have simplified the problem…
>>  
>> My simple setup, which is perfectly able to pull images from GitLab in v3.6, 
>> uses just one secret and does not need the “oc secrets link […]” command. 
>> This simple setup does not work with OpenShift v3.7. Instead I get image 
>> pull errors (shown in attached screenshot).  Is there anyone who’s pulled an 
>> image from GitLab? And can someone explain why my single secret setup works 
>> in 3.6 but does not in 3.7?
>>  
>> Alan.
>>  
>> 
>> 
>> 
>> On 19 Jan 2018, at 15:56, Gaurav P > > wrote:
>>  
>> Louis,
>> 
>> In our case, it is Artifactory. Relevant headers:
>> 
>> HTTP/1.1 401 Unauthorized
>> Server: Artifactory/5.4.5
>> X-Artifactory-Id: 
>> X-Artifactory-Node-Id: 
>> WWW-Authenticate: Basic realm="Artifactory Realm"
>> 
>> Note however that in the case of Artifactory, Docker registries have to be 
>> fronted by haproxy, so the Basic auth might be coming from there...
>>  
>> - Gaurav
>>  
>> On Fri, Jan 19, 2018 at 3:03 AM, Louis Santillan > > wrote:
>> Gaurav, Alan, 
>>  
>> What is the full (redact if necessary for artifactory) output of `curl -kv 
>> https:///v2//`?
>>  
>> I get the following headers when I naively hit 
>> `https://registry.gitlab.com/v2/myproject/myimage/manifests/latest` 
>> 
>> 
>> 1.
>> Content-Length:
>> 
>> 
>> 160
>> 
>> 
>> 2.
>> Content-Type:
>> 
>> 
>> application/json; charset=utf-8
>> 
>> 
>> 3.
>> Date:
>> 
>> 
>> Fri, 19 Jan 2018 07:58:26 GMT
>> 
>> 
>> 4.
>> Docker-Distribution-Api-Version:
>> 
>> 
>> registry/2.0
>> 
>> 
>> 5.
>> Www-Authenticate:
>> 
>> 
>> Bearer realm="https://gitlab.com/jwt/auth 
>> ",service="container_registry",scope="repository:myproject/myimage:pull"
>> 
>> 
>> 6.
>> X-Content-Type-Options:
>> 
>> 
>> nosniff
>> 
>> Looks like `https://gitlab.com/jwt/auth`  is 
>> the auth URL Maciej is speaking of.
>>  
>> The docs also mention having to `link` 

Re: Help using ImageStreams, DCs and ImagePullSecrets templates with a GitLab private registry (v3.6)

[Alan Christie]

Ah ha!

OK, the first approach did not work but your second suggestion worked!! Phew, 
thanks … although I had to remove the “-w0" argument (they’re not recognised on 
OSX). So the following allowed me to pull from gitlab: -

oc create -f - < On 9 Apr 2018, at 21:29, Pavel Gashev  wrote:
> 
> Alan,
>  
> Just try the following:
>  
> # docker login registry.gitlab.com 
> # oc create secret generic --from-file=.dockerconfigjson=.docker/config.json 
> --type=kubernetes.io/dockerconfigjson  
> pullsecret
>  
> another way:
>  
> # GITLAB_USER=user
> # GITLAB_PASSWORD=password
> # oc create -f - < apiVersion: v1
> kind: Secret
> metadata:
>   name: pullsecret
> type: kubernetes.io/dockerconfigjson 
> data:
>   .dockerconfigjson: $(echo -n "{\"auths\":{\"registry.gitlab.com 
> \":{\"auth\":\"`echo -n 
> "$GITLAB_USER:$GITLAB_PASSWORD" | base64 -w0`\"}}}"|base64 -w0)
> EOF
>  
> From:  > on behalf of Alan Christie 
> >
> Date: Monday, 9 April 2018 at 01:57
> To: Gaurav P >
> Cc: users  >
> Subject: Re: Help using ImageStreams, DCs and ImagePullSecrets templates with 
> a GitLab private registry (v3.6)
>  
> Sorry Guys, but I’m getting nowhere here. 
>  
> A long time has passed and I have been doing other things but keep returning 
> to this and trying every single combination of URL that I can but nothing is 
> working for me with GitLab.
>  
> The good news is that I have simplified the problem…
>  
> My simple setup, which is perfectly able to pull images from GitLab in v3.6, 
> uses just one secret and does not need the “oc secrets link […]” command. 
> This simple setup does not work with OpenShift v3.7. Instead I get image pull 
> errors (shown in attached screenshot).  Is there anyone who’s pulled an image 
> from GitLab? And can someone explain why my single secret setup works in 3.6 
> but does not in 3.7?
>  
> Alan.
>  
> 
> 
> 
> On 19 Jan 2018, at 15:56, Gaurav P  > wrote:
>  
> Louis,
> 
> In our case, it is Artifactory. Relevant headers:
> 
> HTTP/1.1 401 Unauthorized
> Server: Artifactory/5.4.5
> X-Artifactory-Id: 
> X-Artifactory-Node-Id: 
> WWW-Authenticate: Basic realm="Artifactory Realm"
> 
> Note however that in the case of Artifactory, Docker registries have to be 
> fronted by haproxy, so the Basic auth might be coming from there...
>  
> - Gaurav
>  
> On Fri, Jan 19, 2018 at 3:03 AM, Louis Santillan  > wrote:
> Gaurav, Alan, 
>  
> What is the full (redact if necessary for artifactory) output of `curl -kv 
> https:///v2//`?
>  
> I get the following headers when I naively hit 
> `https://registry.gitlab.com/v2/myproject/myimage/manifests/latest` 
> 
> 
> 1.
> Content-Length:
> 
> 
> 160
> 
> 
> 2.
> Content-Type:
> 
> 
> application/json; charset=utf-8
> 
> 
> 3.
> Date:
> 
> 
> Fri, 19 Jan 2018 07:58:26 GMT
> 
> 
> 4.
> Docker-Distribution-Api-Version:
> 
> 
> registry/2.0
> 
> 
> 5.
> Www-Authenticate:
> 
> 
> Bearer realm="https://gitlab.com/jwt/auth 
> ",service="container_registry",scope="repository:myproject/myimage:pull"
> 
> 
> 6.
> X-Content-Type-Options:
> 
> 
> nosniff
> 
> Looks like `https://gitlab.com/jwt/auth`  is the 
> auth URL Maciej is speaking of.
>  
> The docs also mention having to `link` the secret to the namespace's 
> `:default` service account for pod image pulling [0].  There's a step or two 
> extra there that Maciej had not yet mentioned.
>  
> [0] 
> https://docs.openshift.com/container-platform/3.7/dev_guide/managing_images.html#allowing-pods-to-reference-images-from-other-secured-registries
>  
> 
> 
> ___
> LOUIS P. SANTILLAN
> ARCHITECT, OPENSHIFT, MIDDLEWARE & DEVOPS
> Red Hat Consulting,  Container and PaaS Practice
> lsant...@redhat.com    M: 3236334854 
> 
> Error! Filename not specified.    
> TRIED. TESTED. TRUSTED. 
>  
> 
>  
> On Thu, Jan 18, 2018 at 2:01 PM, Gaurav P  > wrote:
> Maciej,
> 
> I have a similar problem, however with a private authenticated Artifactory 
> registry fronted by