Tekton on OpenShift: authentication issue with internal OpenShift registry #2258

chanseokoh · 2020-01-29T23:26:37Z

From #2074 (comment)

I did a new test using the following parameters top of ocp3 and that fails using jib-maven 2.0.0

    - name: build-and-push
      image: gcr.io/cloud-builders/mvn
      command:
        - mvn
        - compile
        - com.google.cloud.tools:jib-maven-plugin:2.0.0:build
        - -Djib.from.image=registry.redhat.io/redhat-openjdk-18/openjdk18-openshift
        - -Djib.allowInsecureRegistries=true
        - -Djib.from.auth.username=my-user
        - -Djib.from.auth.password=my-pwd
        - -Dimage=$(outputs.resources.image.url)

If I add to the config too -DsendCredentialsOverHttp=true, then we got this error

[ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:2.0.0:build (default-cli) on project rest-http: 
Build image failed: Failed to authenticate with registry docker-registry.default.svc:5000/test/sb-image 
because: server did not return 'WWW-Authenticate: Bearer' header: Basic 
realm=openshift,error="access denied" -> [Help 1]

The text was updated successfully, but these errors were encountered:

chanseokoh · 2020-01-29T23:34:30Z

The issue is migrated from #2074. Some highlights:

From -Djib.allowInsecureRegistries=true does not seems to work #2074 (comment)

[ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:2.0.0:build (default-cli) on project rest-http: 
Build image failed: Failed to authenticate with registry docker-registry.default.svc:5000/test/sb-image 
because: server did not return 'WWW-Authenticate: Bearer' header: Basic 
realm=openshift,error="access denied" -> [Help 1]
This is weird. This can happen in the following case:

The registry (docker-registry.default.svc:5000) initially requested and accepted bearer authentication. (That is, the registry returned WWW-Authenticate: Bearer ...). The registry successfully returned a working auth token.

Jib uses the returned token for subsequent registry API calls. The token works for a while.

Sometime later, the registry returned "401 Unauthorized" when Jib tried to use the same token, most likely because the token expired after 5 minutes. (I can see the Maven build is taking more than > 5 minutes, although I don't know the exact expiration time of the token.)

Jib now tries to refresh the expired bearer token, but the server returned WWW-Authenticate: Basic ... instead of WWW-Authenticate: Brearer ....

This feels like the server is not returning the right WWW-Authenticate header. The server is supposed to return Bearer instead of Basic in this case.

From -Djib.allowInsecureRegistries=true does not seems to work #2074 (comment)

The registry is an Integrated OpenShift V3 registry.
      image: 'openshift/origin-docker-registry:v3.11.0'

From -Djib.allowInsecureRegistries=true does not seems to work #2074 (comment)

We also get this error even if the maven builds is about 15s

cmoulliard · 2020-01-30T06:16:55Z

Here is the stack trace generated including the HTTP requests : https://gist.github.com/cmoulliard/2a0edd9f2e6e1f3b28539539021e2426

@chanseokoh

cmoulliard · 2020-01-30T06:33:41Z

It looks like that we got an access_token : https://gist.github.com/cmoulliard/2a0edd9f2e6e1f3b28539539021e2426#file-gistfile1-txt-L772-L795
but the step to refresh the token reports an error 401 : unauthorized : https://gist.github.com/cmoulliard/2a0edd9f2e6e1f3b28539539021e2426#file-gistfile1-txt-L1217-L1245

cmoulliard · 2020-01-30T06:50:24Z

FYI. The file containing the credentials to log on to the docker registry is well present
and this is confirmed too by JIB : https://gist.github.com/cmoulliard/2a0edd9f2e6e1f3b28539539021e2426#file-gistfile1-txt-L722

/builder/home/.docker/config.json

$ cat /builder/home/.docker/config.json
{
  "auths": {
    "172.30.1.1:5000": {
      "username": "serviceaccount",
      "password": "eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ0ZXN0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkLWJvdC10b2tlbi00d21ucSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJidWlsZC1ib3QiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI4YWM3MDJjNC00MzI3LTExZWEtOWZjMS05NjAwMDAzOGZlNTUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6dGVzdDpidWlsZC1ib3QifQ.YB205_yEoWPy4peHh72tfyMDSrrCWSlRP03wO91XLE-iHa7fWaNvQrImvpSAg-q5lUG3eVIdcdzP0a0RKe4dHG7_aZpS962ilEdVnNwkw6FoLhn6tDuUWWiBCkR7L6EEPNTjY1REtRKsnnZlp0iw1EBZOnxikXkJifGqKm_n6HF7BrbiqBu8WvoI5DdkynrbmDqjJ7oHg_5-vEgo3LI4qWLOxmRrX2PVkkjIEwtGmtoyvvR1kRdCgJpMLyQho6JqiuB8skFH732dW0708sDKlMlgsXwwSfqt3Twx_uq1OV4Uo52gsLQn26hTnUg5tarym4QVpEAOITpA7PP4xg2xXw",
      "auth": "c2VydmljZWFjY291bnQ6ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSjBaWE4wSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaV055WlhRdWJtRnRaU0k2SW1KMWFXeGtMV0p2ZEMxMGIydGxiaTAwZDIxdWNTSXNJbXQxWW1WeWJtVjBaWE11YVc4dmMyVnlkbWxqWldGalkyOTFiblF2YzJWeWRtbGpaUzFoWTJOdmRXNTBMbTVoYldVaU9pSmlkV2xzWkMxaWIzUWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzUxYVdRaU9pSTRZV00zTURKak5DMDBNekkzTFRFeFpXRXRPV1pqTVMwNU5qQXdNREF6T0dabE5UVWlMQ0p6ZFdJaU9pSnplWE4wWlcwNmMyVnlkbWxqWldGalkyOTFiblE2ZEdWemREcGlkV2xzWkMxaWIzUWlmUS5ZQjIwNV95RW9XUHk0cGVIaDcydGZ5TURTcnJDV1NsUlAwM3dPOTFYTEUtaUhhN2ZXYU52UXJJbXZwU0FnLXE1bFVHM2VWSWRjZHpQMGEwUktlNGRIRzdfYVpwUzk2MmlsRWRWbk53a3c2Rm9MaG42dER1VVdXaUJDa1I3TDZFRVBOVGpZMVJFdFJLc25uWmxwMGl3MUVCWk9ueGlrWGtKaWZHcUttX242SEY3QnJiaXFCdThXdm9JNURka3lucmJtRHFqSjdvSGdfNS12RWdvM0xJNHFXTE94bVJyWDJQVmtraklFd3RHbXRveXZ2UjFrUmRDZ0pwTUx5UWhvNkpxaXVCOHNrRkg3MzJkVzA3MDhzREtsTWxnc1h3d1NmcXQzVHd4X3VxMU9WNFVvNTJnc0xRbjI2aFRuVWc1dGFyeW00UVZwRUFPSVRwQTdQUDR4ZzJ4WHc=",
      "email": "[email protected]"
    },
    "docker-registry.default.svc.cluster.local:5000": {
      "username": "serviceaccount",
      "password": "eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ0ZXN0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkLWJvdC10b2tlbi00d21ucSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJidWlsZC1ib3QiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI4YWM3MDJjNC00MzI3LTExZWEtOWZjMS05NjAwMDAzOGZlNTUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6dGVzdDpidWlsZC1ib3QifQ.YB205_yEoWPy4peHh72tfyMDSrrCWSlRP03wO91XLE-iHa7fWaNvQrImvpSAg-q5lUG3eVIdcdzP0a0RKe4dHG7_aZpS962ilEdVnNwkw6FoLhn6tDuUWWiBCkR7L6EEPNTjY1REtRKsnnZlp0iw1EBZOnxikXkJifGqKm_n6HF7BrbiqBu8WvoI5DdkynrbmDqjJ7oHg_5-vEgo3LI4qWLOxmRrX2PVkkjIEwtGmtoyvvR1kRdCgJpMLyQho6JqiuB8skFH732dW0708sDKlMlgsXwwSfqt3Twx_uq1OV4Uo52gsLQn26hTnUg5tarym4QVpEAOITpA7PP4xg2xXw",
      "auth": "c2VydmljZWFjY291bnQ6ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSjBaWE4wSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaV055WlhRdWJtRnRaU0k2SW1KMWFXeGtMV0p2ZEMxMGIydGxiaTAwZDIxdWNTSXNJbXQxWW1WeWJtVjBaWE11YVc4dmMyVnlkbWxqWldGalkyOTFiblF2YzJWeWRtbGpaUzFoWTJOdmRXNTBMbTVoYldVaU9pSmlkV2xzWkMxaWIzUWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzUxYVdRaU9pSTRZV00zTURKak5DMDBNekkzTFRFeFpXRXRPV1pqTVMwNU5qQXdNREF6T0dabE5UVWlMQ0p6ZFdJaU9pSnplWE4wWlcwNmMyVnlkbWxqWldGalkyOTFiblE2ZEdWemREcGlkV2xzWkMxaWIzUWlmUS5ZQjIwNV95RW9XUHk0cGVIaDcydGZ5TURTcnJDV1NsUlAwM3dPOTFYTEUtaUhhN2ZXYU52UXJJbXZwU0FnLXE1bFVHM2VWSWRjZHpQMGEwUktlNGRIRzdfYVpwUzk2MmlsRWRWbk53a3c2Rm9MaG42dER1VVdXaUJDa1I3TDZFRVBOVGpZMVJFdFJLc25uWmxwMGl3MUVCWk9ueGlrWGtKaWZHcUttX242SEY3QnJiaXFCdThXdm9JNURka3lucmJtRHFqSjdvSGdfNS12RWdvM0xJNHFXTE94bVJyWDJQVmtraklFd3RHbXRveXZ2UjFrUmRDZ0pwTUx5UWhvNkpxaXVCOHNrRkg3MzJkVzA3MDhzREtsTWxnc1h3d1NmcXQzVHd4X3VxMU9WNFVvNTJnc0xRbjI2aFRuVWc1dGFyeW00UVZwRUFPSVRwQTdQUDR4ZzJ4WHc=",
      "email": "[email protected]"
    },
    "docker-registry.default.svc:5000": {
      "username": "serviceaccount",
      "password": "eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ0ZXN0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkLWJvdC10b2tlbi00d21ucSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJidWlsZC1ib3QiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI4YWM3MDJjNC00MzI3LTExZWEtOWZjMS05NjAwMDAzOGZlNTUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6dGVzdDpidWlsZC1ib3QifQ.YB205_yEoWPy4peHh72tfyMDSrrCWSlRP03wO91XLE-iHa7fWaNvQrImvpSAg-q5lUG3eVIdcdzP0a0RKe4dHG7_aZpS962ilEdVnNwkw6FoLhn6tDuUWWiBCkR7L6EEPNTjY1REtRKsnnZlp0iw1EBZOnxikXkJifGqKm_n6HF7BrbiqBu8WvoI5DdkynrbmDqjJ7oHg_5-vEgo3LI4qWLOxmRrX2PVkkjIEwtGmtoyvvR1kRdCgJpMLyQho6JqiuB8skFH732dW0708sDKlMlgsXwwSfqt3Twx_uq1OV4Uo52gsLQn26hTnUg5tarym4QVpEAOITpA7PP4xg2xXw",
      "auth": "c2VydmljZWFjY291bnQ6ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSjBaWE4wSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaV055WlhRdWJtRnRaU0k2SW1KMWFXeGtMV0p2ZEMxMGIydGxiaTAwZDIxdWNTSXNJbXQxWW1WeWJtVjBaWE11YVc4dmMyVnlkbWxqWldGalkyOTFiblF2YzJWeWRtbGpaUzFoWTJOdmRXNTBMbTVoYldVaU9pSmlkV2xzWkMxaWIzUWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzUxYVdRaU9pSTRZV00zTURKak5DMDBNekkzTFRFeFpXRXRPV1pqTVMwNU5qQXdNREF6T0dabE5UVWlMQ0p6ZFdJaU9pSnplWE4wWlcwNmMyVnlkbWxqWldGalkyOTFiblE2ZEdWemREcGlkV2xzWkMxaWIzUWlmUS5ZQjIwNV95RW9XUHk0cGVIaDcydGZ5TURTcnJDV1NsUlAwM3dPOTFYTEUtaUhhN2ZXYU52UXJJbXZwU0FnLXE1bFVHM2VWSWRjZHpQMGEwUktlNGRIRzdfYVpwUzk2MmlsRWRWbk53a3c2Rm9MaG42dER1VVdXaUJDa1I3TDZFRVBOVGpZMVJFdFJLc25uWmxwMGl3MUVCWk9ueGlrWGtKaWZHcUttX242SEY3QnJiaXFCdThXdm9JNURka3lucmJtRHFqSjdvSGdfNS12RWdvM0xJNHFXTE94bVJyWDJQVmtraklFd3RHbXRveXZ2UjFrUmRDZ0pwTUx5UWhvNkpxaXVCOHNrRkg3MzJkVzA3MDhzREtsTWxnc1h3d1NmcXQzVHd4X3VxMU9WNFVvNTJnc0xRbjI2aFRuVWc1dGFyeW00UVZwRUFPSVRwQTdQUDR4ZzJ4WHc=",
      "email": "[email protected]"
    }
  }
}
$

cmoulliard · 2020-01-30T11:06:22Z

I added a comment to the gist to also log the auth part. The access token generated is well used several times but when we want to perform a post, then that fails

CONFIG: -------------- REQUEST  --------------
POST http://docker-registry.default.svc:5000/v2/test/sb-image/blobs/uploads/ 
Accept: 
Accept-Encoding: gzip
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ0ZXN0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkLWJvdC10b2tlbi1sNm02ZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJidWlsZC1ib3QiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI3ZjQxZTA0ZC00MzRmLTExZWEtOWZjMS05NjAwMDAzOGZlNTUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6dGVzdDpidWlsZC1ib3QifQ.a3u24Y4LXooIZmUckgVsI9bPmQ8TsWg-TCtkPDhXYyt_zitocb4H6F0BvuSM0CYFukzot6zQrkarljDPwMfoELG_7yeFZHfPB7eiI_wgd292v7cDVI8G1oCkI4kWuaNGlt_S5fbugh5kCK8J-W0Q6noBzr-YWuYVKmoSzcD_YHudDQLH0kPpB123Tyw-IUUJda-2qsjvQkMRLQ8vGS9TKE_4BpxBesLUjZdSdeixOMSXnY-uIHy9MaRQa1aVwuKoww6Ol8FDPuem6yuVk16DS26BK7-js-g1SaBB4TtFRyX57ApEh50g7iU2hqxls484SO_Xtj1t-8eI7PU_okwkiw
User-Agent: jib 2.0.0 jib-maven-plugin Google-HTTP-Java-Client/1.34.0 (gzip)
Jan 30, 2020 10:59:36 AM com.google.api.client.http.HttpRequest execute
CONFIG: curl -v --compressed -X POST -H 'Accept: ' -H 'Accept-Encoding: gzip' -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ0ZXN0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkLWJvdC10b2tlbi1sNm02ZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJidWlsZC1ib3QiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI3ZjQxZTA0ZC00MzRmLTExZWEtOWZjMS05NjAwMDAzOGZlNTUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6dGVzdDpidWlsZC1ib3QifQ.a3u24Y4LXooIZmUckgVsI9bPmQ8TsWg-TCtkPDhXYyt_zitocb4H6F0BvuSM0CYFukzot6zQrkarljDPwMfoELG_7yeFZHfPB7eiI_wgd292v7cDVI8G1oCkI4kWuaNGlt_S5fbugh5kCK8J-W0Q6noBzr-YWuYVKmoSzcD_YHudDQLH0kPpB123Tyw-IUUJda-2qsjvQkMRLQ8vGS9TKE_4BpxBesLUjZdSdeixOMSXnY-uIHy9MaRQa1aVwuKoww6Ol8FDPuem6yuVk16DS26BK7-js-g1SaBB4TtFRyX57ApEh50g7iU2hqxls484SO_Xtj1t-8eI7PU_okwkiw' -H 'User-Agent: jib 2.0.0 jib-maven-plugin Google-HTTP-Java-Client/1.34.0 (gzip)' -- 'http://docker-registry.default.svc:5000/v2/test/sb-image/blobs/uploads/' 
Jan 30, 2020 10:59:36 AM com.google.api.client.http.HttpResponse <init>
CONFIG: -------------- RESPONSE --------------
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Docker-Distribution-Api-Version: registry/2.0
Www-Authenticate: Basic realm=openshift,error="access denied"
X-Registry-Supports-Signatures: 1
Date: Thu, 30 Jan 2020 10:59:36 GMT
Content-Length: 228
Jan 30, 2020 10:59:36 AM com.google.api.client.util.LoggingByteArrayOutputStream close
CONFIG: Total: 228 bytes
Jan 30, 2020 10:59:36 AM com.google.api.client.util.LoggingByteArrayOutputStream close
CONFIG: {"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"test/sb-image","Action":"pull"},{"Type":"repository","Class":"","Name":"test/sb-image","Action":"push"}]}]}

cmoulliard · 2020-01-30T11:28:26Z

Problem resolved. We need a different role to be able to push to the internal docker registry : https://gist.github.com/cmoulliard/4dc5ad76ef7bf694f70c4e73262e7237

cmoulliard · 2020-01-30T11:49:22Z

Nevertheless, the error reported server did not return 'WWW-Authenticate: Bearer' header: Basic realm=openshift,error="access denied" will never help the end user to understand what is the issue/root cause. Wo, how can we improve that ? @chanseokoh

adambkaplan · 2020-01-30T15:13:02Z

@cmoulliard shouldn't the built-in image-pusher role be sufficient? I believe this role is bound to the builder service account, which is added to every OpenShift project by default.

cmoulliard · 2020-01-30T15:19:58Z

role be sufficient?

@adambkaplan image-pusher is not enough but registry-editor works.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: registry-editor
rules:
- apiGroups:
  - ""
  resources:
  - secrets
  - serviceaccounts
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  - image.openshift.io
  resources:
  - imagestreamimages
  - imagestreammappings
  - imagestreams
  - imagestreams/secrets
  - imagestreamtags
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  - image.openshift.io
  resources:
  - imagestreamimports
  verbs:
  - create
- apiGroups:
  - ""
  - image.openshift.io
  resources:
  - imagestreams/layers
  verbs:
  - get
  - update
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
- apiGroups:
  - ""
  - project.openshift.io
  resources:
  - projects
  verbs:
  - get

chanseokoh · 2020-01-30T16:27:26Z

@cmoulliard thank you very much for the investigation! Now it's clear what's going on. We can certainly work together to improve this situation.

You are right that Jib has successfully authenticated with the registry to get a bearer token for the target repository (docker-registry.default.svc:5000/test/sb-image).

CONFIG: -------------- REQUEST  --------------
GET http://docker-registry.default.svc:5000/openshift/token?service=docker-registry.default.svc:5000&scope=repository:test/sb-image:pull,push 
Authorization: <Not Logged>

CONFIG: -------------- RESPONSE --------------
HTTP/1.1 200 OK
{"access_token":"...", "token":"..."}

Note Jib requested both pull and push scopes for the repository test/sb-image.

scope=repository:test/sb-image:pull,push

However, my guess is that the registry decided to grant only the pull scope and not push (probably because your account lacked a push role). The returned token certainly worked for pull (e.g., HEAD https://docker-registry.default.svc:5000/v2/test/sb-image/blobs/sha256:...). However, for push (e.g., POST http://docker-registry.default.svc:5000/v2/test/sb-image/blobs/uploads), it returned "401 Unauthorized" when using the token.

And I think it is not wrong that an auth server returns "200 OK" when the returned token doesn't include all the requested scopes, according to the Docker authentication spec:

If the client only has a subset of the requested access it must not be considered an error as it is not the responsibility of the token server to indicate authorization errors as part of this workflow.

Continuing with the example request, the token server will find that the client’s set of granted access to the repository is [pull, push] which when intersected with the requested access [pull, push] yields an equal set. If the granted access set was found only to be [pull] then the intersected set would only be [pull]. If the client has no access to the repository then the intersected set would be empty, [].

If my guess is correct, then I think the registry isn't at fault at this point.

Then, it is very much expected that a push request (POST http://docker-registry.default.svc:5000/v2/test/sb-image/blobs/uploads) will not go through with the returned token. However, I think the server should return "403 Forbidden" instead of "401 Unauthorized". The user has successfully authenticated with the registry (the user got the bearer token), the registry verified the identity of the user, and it's just that the user explicitly lacks the role to push. If the registry returned "403 Forbidden", Jib would have printed out the right error message which points to this FAQ entry.

If the registry returns 403 Forbidden or "code":"DENIED", it often means Jib successfully authenticated using your credentials but the credentials do not have permissions to pull or push images. Make sure your account/role has the permissions to do the operation.

But in this case, the registry returned 401 saying "authentication required", and that is confusing, because the user already authenticated with the registry. The registry already knows who the user is.

{"errors":[{"code":"UNAUTHORIZED","message":"authentication required", ...

But I admit Jib should be fully prepared to handle this case intelligently and provide a more helpful error message. I haven't really thought about this scenario; it's insightful.

chanseokoh · 2020-01-30T16:32:35Z

One more question:

When Jib first tried to access the integrated registry, it asked Jib to perform bearer token auth:

HTTP/1.1 401 Unauthorized
...
Www-Authenticate: Bearer realm="http://docker-registry.default.svc:5000/openshift/token "

However, when the returned token didn't have push scope, it asked for basic auth:

HTTP/1.1 401 Unauthorized
...
Www-Authenticate: Basic realm=openshift,error="access denied"

Is this intended? Does the registry support both basic and bearer auth? It doesn't matter which auth is used?

adambkaplan · 2020-01-30T16:49:55Z

fyi @dmage

cmoulliard · 2020-01-31T09:30:06Z

@dmage Could you please help us here ?

dmage · 2020-01-31T11:14:57Z

The integrated image registry supports both methods, but perhaps we should be consistent and use only Bearer in our errors.

dmage · 2020-01-31T11:28:38Z

About 403 Forbidden, while I agree with arguments, I want our behaviour to be consistent with DockerHub.

2020/01/31 12:20:17 -> GET https://index.docker.io/v2/dmage/private/manifests/latest HTTP/1.1
2020/01/31 12:20:17 -> Authorization: Bearer eyJhbGci...<REDACTED>...ttSYBFFIQ
2020/01/31 12:20:17 ->
2020/01/31 12:20:17 <- HTTP/1.1 401 Unauthorized
2020/01/31 12:20:17 <- Content-Length: 156
2020/01/31 12:20:17 <- Content-Type: application/json
2020/01/31 12:20:17 <- Date: Fri, 31 Jan 2020 11:20:17 GMT
2020/01/31 12:20:17 <- Docker-Distribution-Api-Version: registry/2.0
2020/01/31 12:20:17 <- Strict-Transport-Security: max-age=31536000
2020/01/31 12:20:17 <- Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:dmage/private:pull",error="insufficient_scope"
2020/01/31 12:20:17 <-
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"dmage/private","Action":"pull"}]}]}

chanseokoh · 2020-01-31T15:52:54Z

I want our behaviour to be consistent with DockerHub.

That's fair. Jib should be smarter to handle this case for better usability anyway.

cmoulliard · 2020-01-31T15:55:50Z

@adambkaplan @dmage I'm experimenting another problem using a use case similar but now JIB gets an Anonymous Bearer - https://gist.github.com/cmoulliard/10fd94f3509d02af6a16abd3d2b32ce8#file-gistfile1-txt-L575

Do you know why we get such response ?

@chanseokoh JIB of course will reports this message which is also weird

Failed to authenticate with registry docker-registry.default.svc:5000/test/quarkus-demo because: server did not return 'WWW-Authenticate: Bearer' header: Basic realm=openshift,error="access denied"

The docker registry complaints about a RBAC issue

time="2020-01-31T16:42:24.845069423Z" level=error msg="OpenShift access denied: no RBAC policy matched" go.version=go1.10.3 http.request.host="172.30.1.1:5000" http.request.id=b2cdb228-35aa-446e-bd20-23a2746aa931 http.request.method=HEAD http.request.remoteaddr="172.17.0.15:55938" http.request.uri="/v2/test/quarkus-demo/blobs/sha256:00f17e0b37b0515380a4aece3cb72086c0356fc780ef4526f75476bea36a2c8b" http.request.useragent="jib 2.0.0 jib-maven-plugin Google-HTTP-Java-Client/1.34.0 (gzip)" instance.id=41d4c79e-6b14-4226-ac62-319748230ac5 openshift.auth.user=anonymous vars.digest="sha256:00f17e0b37b0515380a4aece3cb72086c0356fc780ef4526f75476bea36a2c8b" vars.name=test/quarkus-demo
--
  | time="2020-01-31T16:42:24.845199879Z" level=warning msg="error authorizing context: access denied" go.version=go1.10.3 http.request.host="172.30.1.1:5000" http.request.id=b2cdb228-35aa-446e-bd20-23a2746aa931 http.request.method=HEAD http.request.remoteaddr="172.17.0.15:55938" http.request.uri="/v2/test/quarkus-demo/blobs/sha256:00f17e0b37b0515380a4aece3cb72086c0356fc780ef4526f75476bea36a2c8b" http.request.useragent="jib 2.0.0 jib-maven-plugin Google-HTTP-Java-Client/1.34.0 (gzip)" instance.id=41d4c79e-6b14-4226-ac62-319748230ac5 vars.digest="sha256:00f17e0b37b0515380a4aece3cb72086c0356fc780ef4526f75476bea36a2c8b" vars.name=test/quarkus-demo

while the ServiceAccount mounted to the pod is linked to the role registry-editor

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: registry-editor
  namespace: test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: registry-editor
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts:test

and

oc get pod/quarkus-6c857689c6-8pv6f -o yaml | grep serviceAccount
  serviceAccount: build-bot
  serviceAccountName: build-bot

chanseokoh · 2020-01-31T16:51:54Z

Returning a plain string as a token doesn't look conventional, but it may be OK. Usually a bearer token is a JWT token as explain in https://jwt.io/introduction/. For example, if I decode your token from your previous Jib log, I see something like

{
  "jti": "50dfb273-baac-4359-b934-0d3151d07414",
  "exp": 1580365099,
  "nbf": 1580364799,
  "iat": 1580364799,
  "iss": "https://sso.redhat.com/auth/realms/rhcc",
  "aud": "docker-registry",
  "sub": "rh-gs-cmoullia",
  "typ": "Bearer",
  "azp": "docker-registry",
  "access": []
}

However, I think it is not a big deal if the auth server or the registry decided to return some arbitrary free-form string as long as they will handle such a string in their own way by design.

Returning the string anonymous may or may not be intended. But I can see that, with the auth request below

CONFIG: -------------- REQUEST  --------------
GET http://docker-registry.default.svc:5000/openshift/token?service=docker-registry.default.svc:5000&scope=repository:test/quarkus-demo:pull,push
Accept: */*
Accept-Encoding: gzip
User-Agent: jib 2.0.0 jib-maven-plugin Google-HTTP-Java-Client/1.34.0 (gzip)

Jib didn't pass any credentials (username and password). If Jib were able to retrieve any credentials for the registry, it could have sent the username and password pair through the Authorization header to the auth server:

Authorization: Basic <base64 encoding of username + ":" + password>

There was no Authorization header, meaning that Jib couldn't find any credentials for your registry. That's probably why the registry returned anonymous. If Jib can retrieve a credential, you will see a log like

[INFO] Using credentials from ... for docker-registry.default.svc:5000/test/quarkus-demo

cmoulliard · 2020-01-31T17:01:34Z

Jib didn't pass any credentials (username and password). I

The dockercfg file has been mounted to the pod as it is available here

sh-4.4$ pwd
/home/jboss

sh-4.4$ ls -la .docker/.dockercfg
lrwxrwxrwx. 1 root root 17 Jan 31 16:50 .docker/.dockercfg -> ..data/.dockercfg

sh-4.4$ cat .docker/.dockercfg
{"172.30.1.1:5000":{"username":"serviceaccount","password":"eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ0ZXN0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkLWJvdC10b2tlbi1yd3hybiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJidWlsZC1ib3QiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI4MGYwNmQwOC00NDM2LTExZWEtOWZjMS05NjAwMDAzOGZlNTUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6dGVzdDpidWlsZC1ib3QifQ.e7aZAi4ZaEheGhYCbEADpsHe_70BX_GCh8foNQ7OTveKqnUqpg29x-aJUGv8jrtpdQ9keupzsKlO7X1D8UTf58gLzIN0JEOn0NhQ9CV009QlHTpDueTaB4wB8a44-wm7Azg9nvrIAG0kfn66lvFpaQcqFbuEEa3coo8_OTjat4vtm2ra8P2j2H7J3qLQ6nVE76WYryobFlz3zuTluwT7K8-DrbL4hEoBf4VFQeWW_Z8NLZtyDj39YpBTuklMMDm6p7diq9UcEQee2UwtO1qMp2bPEXn-vYFvuDASszIqsiUmSyFcFE3I2_3Y3YZKw53x6YLm-UNtNiNYwC-o_KY8rA","email":"[email protected]","auth":"c2VydmljZWFjY291bnQ6ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSjBaWE4wSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaV055WlhRdWJtRnRaU0k2SW1KMWFXeGtMV0p2ZEMxMGIydGxiaTF5ZDNoeWJpSXNJbXQxWW1WeWJtVjBaWE11YVc4dmMyVnlkbWxqWldGalkyOTFiblF2YzJWeWRtbGpaUzFoWTJOdmRXNTBMbTVoYldVaU9pSmlkV2xzWkMxaWIzUWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzUxYVdRaU9pSTRNR1l3Tm1Rd09DMDBORE0yTFRFeFpXRXRPV1pqTVMwNU5qQXdNREF6T0dabE5UVWlMQ0p6ZFdJaU9pSnplWE4wWlcwNmMyVnlkbWxqWldGalkyOTFiblE2ZEdWemREcGlkV2xzWkMxaWIzUWlmUS5lN2FaQWk0WmFFaGVHaFlDYkVBRHBzSGVfNzBCWF9HQ2g4Zm9OUTdPVHZlS3FuVXFwZzI5eC1hSlVHdjhqcnRwZFE5a2V1cHpzS2xPN1gxRDhVVGY1OGdMeklOMEpFT24wTmhROUNWMDA5UWxIVHBEdWVUYUI0d0I4YTQ0LXdtN0F6ZzludnJJQUcwa2ZuNjZsdkZwYVFjcUZidUVFYTNjb284X09UamF0NHZ0bTJyYThQMmoySDdKM3FMUTZuVkU3NldZcnlvYkZsejN6dVRsdXdUN0s4LURyYkw0aEVvQmY0VkZRZVdXX1o4TkxadHlEajM5WXBCVHVrbE1NRG02cDdkaXE5VWNFUWVlMlV3dE8xcU1wMmJQRVhuLXZZRnZ1REFTc3pJcXNpVW1TeUZjRkUzSTJfM1kzWVpLdzUzeDZZTG0tVU50TmlOWXdDLW9fS1k4ckE="},"docker-registry.default.svc.cluster.local:5000":{"username":"serviceaccount","password":"eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ0ZXN0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkLWJvdC10b2tlbi1yd3hybiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJidWlsZC1ib3QiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI4MGYwNmQwOC00NDM2LTExZWEtOWZjMS05NjAwMDAzOGZlNTUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6dGVzdDpidWlsZC1ib3QifQ.e7aZAi4ZaEheGhYCbEADpsHe_70BX_GCh8foNQ7OTveKqnUqpg29x-aJUGv8jrtpdQ9keupzsKlO7X1D8UTf58gLzIN0JEOn0NhQ9CV009QlHTpDueTaB4wB8a44-wm7Azg9nvrIAG0kfn66lvFpaQcqFbuEEa3coo8_OTjat4vtm2ra8P2j2H7J3qLQ6nVE76WYryobFlz3zuTluwT7K8-DrbL4hEoBf4VFQeWW_Z8NLZtyDj39YpBTuklMMDm6p7diq9UcEQee2UwtO1qMp2bPEXn-vYFvuDASszIqsiUmSyFcFE3I2_3Y3YZKw53x6YLm-UNtNiNYwC-o_KY8rA","email":"[email protected]","auth":"c2VydmljZWFjY291bnQ6ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSjBaWE4wSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaV055WlhRdWJtRnRaU0k2SW1KMWFXeGtMV0p2ZEMxMGIydGxiaTF5ZDNoeWJpSXNJbXQxWW1WeWJtVjBaWE11YVc4dmMyVnlkbWxqWldGalkyOTFiblF2YzJWeWRtbGpaUzFoWTJOdmRXNTBMbTVoYldVaU9pSmlkV2xzWkMxaWIzUWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzUxYVdRaU9pSTRNR1l3Tm1Rd09DMDBORE0yTFRFeFpXRXRPV1pqTVMwNU5qQXdNREF6T0dabE5UVWlMQ0p6ZFdJaU9pSnplWE4wWlcwNmMyVnlkbWxqWldGalkyOTFiblE2ZEdWemREcGlkV2xzWkMxaWIzUWlmUS5lN2FaQWk0WmFFaGVHaFlDYkVBRHBzSGVfNzBCWF9HQ2g4Zm9OUTdPVHZlS3FuVXFwZzI5eC1hSlVHdjhqcnRwZFE5a2V1cHpzS2xPN1gxRDhVVGY1OGdMeklOMEpFT24wTmhROUNWMDA5UWxIVHBEdWVUYUI0d0I4YTQ0LXdtN0F6ZzludnJJQUcwa2ZuNjZsdkZwYVFjcUZidUVFYTNjb284X09UamF0NHZ0bTJyYThQMmoySDdKM3FMUTZuVkU3NldZcnlvYkZsejN6dVRsdXdUN0s4LURyYkw0aEVvQmY0VkZRZVdXX1o4TkxadHlEajM5WXBCVHVrbE1NRG02cDdkaXE5VWNFUWVlMlV3dE8xcU1wMmJQRVhuLXZZRnZ1REFTc3pJcXNpVW1TeUZjRkUzSTJfM1kzWVpLdzUzeDZZTG0tVU50TmlOWXdDLW9fS1k4ckE="},"docker-registry.default.svc:5000":{"username":"serviceaccount","password":"eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ0ZXN0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImJ1aWxkLWJvdC10b2tlbi1yd3hybiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJidWlsZC1ib3QiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI4MGYwNmQwOC00NDM2LTExZWEtOWZjMS05NjAwMDAzOGZlNTUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6dGVzdDpidWlsZC1ib3QifQ.e7aZAi4ZaEheGhYCbEADpsHe_70BX_GCh8foNQ7OTveKqnUqpg29x-aJUGv8jrtpdQ9keupzsKlO7X1D8UTf58gLzIN0JEOn0NhQ9CV009QlHTpDueTaB4wB8a44-wm7Azg9nvrIAG0kfn66lvFpaQcqFbuEEa3coo8_OTjat4vtm2ra8P2j2H7J3qLQ6nVE76WYryobFlz3zuTluwT7K8-DrbL4hEoBf4VFQeWW_Z8NLZtyDj39YpBTuklMMDm6p7diq9UcEQee2UwtO1qMp2bPEXn-vYFvuDASszIqsiUmSyFcFE3I2_3Y3YZKw53x6YLm-UNtNiNYwC-o_KY8rA","email":"[email protected]","auth":"c2VydmljZWFjY291bnQ6ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSjBaWE4wSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaV055WlhRdWJtRnRaU0k2SW1KMWFXeGtMV0p2ZEMxMGIydGxiaTF5ZDNoeWJpSXNJbXQxWW1WeWJtVjBaWE11YVc4dmMyVnlkbWxqWldGalkyOTFiblF2YzJWeWRtbGpaUzFoWTJOdmRXNTBMbTVoYldVaU9pSmlkV2xzWkMxaWIzUWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzUxYVdRaU9pSTRNR1l3Tm1Rd09DMDBORE0yTFRFeFpXRXRPV1pqTVMwNU5qQXdNREF6T0dabE5UVWlMQ0p6ZFdJaU9pSnplWE4wWlcwNmMyVnlkbWxqWldGalkyOTFiblE2ZEdWemREcGlkV2xzWkMxaWIzUWlmUS5lN2FaQWk0WmFFaGVHaFlDYkVBRHBzSGVfNzBCWF9HQ2g4Zm9OUTdPVHZlS3FuVXFwZzI5eC1hSlVHdjhqcnRwZFE5a2V1cHpzS2xPN1gxRDhVVGY1OGdMeklOMEpFT24wTmhROUNWMDA5UWxIVHBEdWVUYUI0d0I4YTQ0LXdtN0F6ZzludnJJQUcwa2ZuNjZsdkZwYVFjcUZidUVFYTNjb284X09UamF0NHZ0bTJyYThQMmoySDdKM3FMUTZuVkU3NldZcnlvYkZsejN6dVRsdXdUN0s4LURyYkw0aEVvQmY0VkZRZVdXX1o4TkxadHlEajM5WXBCVHVrbE1NRG02cDdkaXE5VWNFUWVlMlV3dE8xcU1wMmJQRVhuLXZZRnZ1REFTc3pJcXNpVW1TeUZjRkUzSTJfM1kzWVpLdzUzeDZZTG0tVU50TmlOWXdDLW9fS1k4ckE="}}
sh-4.4$

and JIB is configured as such

mvn -f /home/jboss/quarkus-demo/pom.xml compile com.google.cloud.tools:jib-maven-plugin:2.0.0:build \
-Djib.from.image=registry.redhat.io/redhat-openjdk-18/openjdk18-openshift \
-Dimage=172.30.1.1:5000/test/quarkus-demo \
-Djib.from.auth.username=xxxxx \
-Djib.from.auth.password=yyyyyy \
-Djib.container.mainClass=dev.snowdrop.HelloApplication \
-DsendCredentialsOverHttp=true 
-Djib.allowInsecureRegistries=true

and 

sh-4.4$ export
export DOCKER_CONFIG="/home/jboss/.docker/"

Do I miss something @chanseokoh ?

chanseokoh · 2020-01-31T17:11:23Z

$ ls -la .docker/.dockercfg

Interesting. We look for $HOME/.docker/config.json. Looks like .dockercfg is an old name. Jib can definitely check .dockercfg if config.json is missing. Filed #2260.

@cmoulliard do you have config.json in the directory, or only .dockercfg?

cmoulliard · 2020-01-31T17:14:22Z

do you have config.json in the directory, or only .dockercfg?

only .dockercfg. I will see if I can rename it to config.json from the secret mounted

chanseokoh · 2020-01-31T17:18:15Z

@chanseokoh JIB of course will reports this message which is also weird

server did not return 'WWW-Authenticate: Bearer' header:

Just to clarify the current Jib behavior: if the registry initially requested bearer auth and the bearer auth succeeded, Jib assumes that the registry is set up to require bearer auth and not basic auth. However, as explained in #2258 (comment), the registry unusually asks for basic auth later. This inconsistency is a bit unusual given that Jib successfully completed the bearer auth before, so the current Jib code errors out. I guess this registry inconsistency is an oversight when implementing the bearer auth in the integrated registry (which I believe is based on the Docker Distribution).

chanseokoh · 2020-02-25T22:22:18Z

@cmoulliard we've released Jib 2.1.0 with this fix. You should no longer see the error about server did not return 'WWW-Authenticate: Bearer' header.

chanseokoh mentioned this issue Jan 29, 2020

-Djib.allowInsecureRegistries=true does not seems to work #2074

Closed

cmoulliard mentioned this issue Jan 30, 2020

Tekton jib-maven fails to push image to the internal docker registry tektoncd/catalog#172

Closed

This was referenced Jan 31, 2020

Try .docker/.dockercfg and $HOME/.docker/... too #2260

Closed

Fall back to initial authenticator if bad response #2261

Merged

chanseokoh added this to the v2.1.0 milestone Jan 31, 2020

chanseokoh closed this as completed in #2261 Feb 6, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tekton on OpenShift: authentication issue with internal OpenShift registry #2258

Tekton on OpenShift: authentication issue with internal OpenShift registry #2258

chanseokoh commented Jan 29, 2020 •

edited

Loading

chanseokoh commented Jan 29, 2020

cmoulliard commented Jan 30, 2020

cmoulliard commented Jan 30, 2020

cmoulliard commented Jan 30, 2020 •

edited by chanseokoh

Loading

cmoulliard commented Jan 30, 2020

cmoulliard commented Jan 30, 2020

cmoulliard commented Jan 30, 2020

adambkaplan commented Jan 30, 2020

cmoulliard commented Jan 30, 2020

chanseokoh commented Jan 30, 2020 •

edited

Loading

chanseokoh commented Jan 30, 2020

adambkaplan commented Jan 30, 2020

cmoulliard commented Jan 31, 2020

dmage commented Jan 31, 2020

dmage commented Jan 31, 2020

chanseokoh commented Jan 31, 2020

cmoulliard commented Jan 31, 2020 •

edited

Loading

chanseokoh commented Jan 31, 2020 •

edited

Loading

cmoulliard commented Jan 31, 2020

chanseokoh commented Jan 31, 2020 •

edited

Loading

cmoulliard commented Jan 31, 2020

chanseokoh commented Jan 31, 2020 •

edited

Loading

chanseokoh commented Feb 25, 2020

Tekton on OpenShift: authentication issue with internal OpenShift registry #2258

Tekton on OpenShift: authentication issue with internal OpenShift registry #2258

Comments

chanseokoh commented Jan 29, 2020 • edited Loading

chanseokoh commented Jan 29, 2020

cmoulliard commented Jan 30, 2020

cmoulliard commented Jan 30, 2020

cmoulliard commented Jan 30, 2020 • edited by chanseokoh Loading

cmoulliard commented Jan 30, 2020

cmoulliard commented Jan 30, 2020

cmoulliard commented Jan 30, 2020

adambkaplan commented Jan 30, 2020

cmoulliard commented Jan 30, 2020

chanseokoh commented Jan 30, 2020 • edited Loading

chanseokoh commented Jan 30, 2020

adambkaplan commented Jan 30, 2020

cmoulliard commented Jan 31, 2020

dmage commented Jan 31, 2020

dmage commented Jan 31, 2020

chanseokoh commented Jan 31, 2020

cmoulliard commented Jan 31, 2020 • edited Loading

chanseokoh commented Jan 31, 2020 • edited Loading

cmoulliard commented Jan 31, 2020

chanseokoh commented Jan 31, 2020 • edited Loading

cmoulliard commented Jan 31, 2020

chanseokoh commented Jan 31, 2020 • edited Loading

chanseokoh commented Feb 25, 2020

chanseokoh commented Jan 29, 2020 •

edited

Loading

cmoulliard commented Jan 30, 2020 •

edited by chanseokoh

Loading

chanseokoh commented Jan 30, 2020 •

edited

Loading

cmoulliard commented Jan 31, 2020 •

edited

Loading

chanseokoh commented Jan 31, 2020 •

edited

Loading

chanseokoh commented Jan 31, 2020 •

edited

Loading

chanseokoh commented Jan 31, 2020 •

edited

Loading