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

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

It may (or may not) make sense to check .dockercfg. Looks like it was an old config name. Note .dockercfg has a different JSON structure. Seems like .dockercfg is from a really old Docker version.

But more importantly, I think we should also try $HOME in addition to System.getProperty("user.home"): #2260 (comment)

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

cmoulliard · 2020-01-31T17:53:37Z

The issue is that when we create the secret containing the file about the docker credentials, kubernetes proposes 2 formats including the new but the filename is different.

So, when they will be mounted from the generated secret, then they will be created as such

old: $HOME/.docker/.dockercfg
new: $HOME/.docker/.dockerconfigjson

cmoulliard · 2020-01-31T18:06:54Z

I still get a Bearer anonymous even if I use the config.json file

sh-4.4$ls -la /home/jboss/.docker/config.json
lrwxrwxrwx. 1 root root 18 Jan 31 17:57 /home/jboss/.docker/config.json -> ..data/config.json
sh-4.4$ cat /home/jboss/.docker/config.json
{
  "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$

Log file : https://gist.githubusercontent.com/cmoulliard/95fc318735cf5252024760168896a42a/raw/8d04f46f535ef8c5a844ec8ae5ad6fdf2b8c2b39/gistfile1.txt

chanseokoh · 2020-01-31T18:16:16Z

Somehow, it still couldn't retrieve credentials for the target image. If all goes well, you should see something like

[INFO] Using credentials from ... for 172.30.1.1:5000/...

Can you try passing -Duser.home=/home/jboss to Maven? Because we use System.getProperty("user.home") instead of reading the $HOME environment variable; they can be different. (This is the case for Google Cloud Build too.)

cmoulliard · 2020-01-31T18:25:38Z

I added the parameter as you suggested -Duser.home=/home/jboss, changed the format of the config.json file to also include auths: and now I see

[INFO] Using credentials from Docker config (/home/jboss/.docker/config.json) for 172.30.1.1:5000/test/quarkus-demo

but we got another error : https://gist.github.com/cmoulliard/945a461e2abc33d222177a553bb1a0ae#file-gistfile1-txt-L398

This error is perhaps related to the fact that the config.json file that I'm using has been created manually and dont use the one generated by kubernetes/openshift :-(

Log of the docker registry is reporting invalid token

time="2020-01-31T18:30:27.171143938Z" level=error msg="invalid token: Unauthorized" go.version=go1.10.3 http.request.host="172.30.1.1:5000" http.request.id=d798df70-d1f3-42af-b9a8-cf282110ddb6 http.request.method=GET http.request.remoteaddr="172.17.0.15:34440" http.request.uri="/openshift/token?service=172.30.1.1:5000&scope=repository:test/quarkus-demo:pull,push" 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

chanseokoh · 2020-01-31T19:03:34Z

Great that -Duser.home worked.

This error is perhaps related to the fact that the config.json file that I'm using has been created manually and dont use the one generated by kubernetes/openshift :-(

Likely. The content of your password (eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9...Lm-UNtNiNYwC-o_KY8rA) doesn't seem wrong syntactically. When I decode it on https://jwt.io/, it is a proper JSON structure.

{
  "alg": "RS256",
  "kid": ""
}
{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "test",
  "kubernetes.io/serviceaccount/secret.name": "build-bot-token-rwxrn",
  "kubernetes.io/serviceaccount/service-account.name": "build-bot",
  "kubernetes.io/serviceaccount/service-account.uid": "80f06d08-4436-11ea-9fc1-96000038fe55",
  "sub": "system:serviceaccount:test:build-bot"
}
...

This password is being passed as Authorization: Basic c2VydmljZWFjY291bnQ6ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbG.... When you decode this string (base64 -d <<< c2Vy...), you get serviceaccount:eyJ... (i.e., <username>:<password> from your config.json). All seems normal. And from your previous build log, we can verify that this auth flow does work.

(from https://gist.github.com/cmoulliard/2a0edd9f2e6e1f3b28539539021e2426)

Authorization: Basic c2VydmljZWFjY291bnQ6ZXlKaGJ...
User-Agent: jib 2.0.0 jib-maven-plugin Google-HTTP-Java-Client/1.34.0 (gzip)
...
CONFIG: -------------- RESPONSE --------------
HTTP/1.1 200 OK
...
CONFIG: {"access_token":"eyJhbGc...","token":"eyJhbGciOi..."}

So I think it's just that the password in config.json is not what the registry expects.

cmoulliard · 2020-01-31T19:40:22Z

So I think it's just that the password in config.json is not what the registry expects

That means that for the moment, if we want to perform a build on openshift and that we push the image to the docker internal registry using JIB, then we must use a pre-step able to convert the .dockercfg file into a a correct config.json file.

This is what tekton is doing as pre-step here : https://github.com/tektoncd/pipeline/blob/master/pkg/credentials/dockercreds/creds.go#L151

chanseokoh · 2020-01-31T19:54:48Z

Ah, I didn't realized .dockercfg and config.json have different JSON structures. There doesn't seem anything wrong with your manual conversion. There may be a different reason that the registry returned 401. Looking at the log, everything seems normal. It just seems like the registry doesn't accept your password for some internal reason (e.g., your service account is not really valid).

cmoulliard · 2020-01-31T20:07:41Z

your password for some internal reason

Right according to this log of the docker registry

time="2020-01-31T19:59:16.93964079Z" level=error msg="invalid token: Unauthorized" go.version=go1.10.3 http.request.host="172.30.1.1:5000" http.request.id=dc1c5617-a360-48ab-bae8-0fdc360a242c http.request.method=GET http.request.remoteaddr="172.17.0.18:55142" http.request.uri="/openshift/token?service=172.30.1.1:5000&scope=repository:test/quarkus-demo:pull,push" 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

Remarks :

As I copied the config.json file from a pod created for a Tekton JIB build, then this is why it dont work.
Unfortunately, as openshift creates for the serviceaccount used by the pod (doing the jib build), a secret containing the old docker format to access the docker internal registry, then I dont see an easy solution to change that for the moment. Why ? We have 2 options:
- we ask openshift/kubernetes teams to generate the file using as name config.json OR
- we extend jib to support the conversion of the old format to the new

@dmage @chanseokoh

dmage · 2020-02-01T16:10:33Z

@cmoulliard Kubernetes has two types of secrets: kubernetes.io/dockercfg and kubernetes.io/dockerconfigjson and none of them is deprecated. I don't think we can change the type (and the format) of the secret that we create for the integrated registry, because it's backward incompatible change.

cmoulliard · 2020-02-01T18:24:28Z

and none of them is deprecated

I agree but the issue is that currently on ocp only the secret containing the old format is populated and not the new one needed by JBI.

kc get secrets
NAME                        TYPE                                  DATA   AGE
build-bot-dockercfg-rwdnx   kubernetes.io/dockercfg               1      20h
build-bot-token-qfdlx       kubernetes.io/service-account-token   4      20h
build-bot-token-xhf8k       kubernetes.io/service-account-token   4      20h

@dmage

dmage · 2020-02-01T23:53:51Z

Why is it an issue? Kubelet and other tools usually support both formats and there is no reason to create a second secret in another format. No matter what type you have, you can link the secret to a service account and it will be used for pulling images.

That's how it is implemented in Kubernetes: https://github.com/kubernetes/kubernetes/blob/7f23a743e8c23ac6489340bbb34fa6f1d392db9d/pkg/credentialprovider/secrets/secrets.go#L29
and in OpenShift Builder:
https://github.com/openshift/builder/blob/99b01e1654cfb141257697631fc60bb71e460245/pkg/build/builder/cmd/dockercfg/cfg.go#L104

cmoulliard · 2020-02-03T07:34:05Z

@dmage. The concern/issue that we have is that currently Openshift only populates the old docker config format within a secret for the serviceaccount
build-bot-dockercfg-rwdnx kubernetes.io/dockercfg and not the new one kubernetes.io/dockerconfigjson

Is there a way to tell to openshift to populate the secret with the type kubernetes.io/dockerconfigjson ?

dmage · 2020-02-03T10:40:33Z

It's not an issue. If your tool works with Kubernetes secrets, it should support both formats.

cmoulliard · 2020-02-03T10:54:28Z

Is there a way to tell to openshift to populate the secret with the type kubernetes.io/dockerconfigjson ?

Till JIB fixes the problem to support the old docker config format, can you tell us how to resolve that please in order to use the new one ? @dmage

dmage · 2020-02-03T11:02:11Z

@cmoulliard OpenShift populates secrets only in one format, you cannot change this.

briandealwis · 2020-02-03T15:53:50Z

@dmage: It's not an issue. If your tool works with Kubernetes secrets, it should support both formats.

Jib does not work with Kubernetes secrets. The .dockercfg is a legacy format that was was effectively deprecated nearly 5 years ago.

dmage · 2020-02-03T16:32:34Z

The .dockercfg is a legacy format that was was effectively deprecated nearly 5 years ago.

@briandealwis still OpenShift can't change the format because of backward compatibility: other tools may rely on the secret format. We can change it only with another major release.

Jib does not work with Kubernetes secrets.

Well, it does. Or you wouldn't have this problem.

chanseokoh · 2020-02-03T17:25:01Z

Jib does not work with Kubernetes secrets.

@dmage I believe what @briandealwis tried to say is that fundamentally Jib is not a tool for k8s. Jib neither interfaces with k8s nor requires it. It happens to be that @cmoulliard tried to run Jib on the k8s platform for whatever reasons.

But I think it is not terribly difficult to read the old Docker config format; looks like I just need to wrap the entire JSON of the old format with an outer "auths" JSON field for conversion.

cmoulliard · 2020-02-03T20:04:34Z

@chanseokoh Do you agree that we update this part of the code in order to :

Add another JIB property to pass the docker file name: config.json, docker.cfg, ...
Modify the code to read old or new docker format
Convert old to new format (wrap the entire JSON in the old format in an additional "auths" JSON field)

loosebazooka · 2020-02-03T20:12:18Z

I hope we don't need to add new properties, can we just handle this in a known order?

chanseokoh · 2020-02-03T20:19:20Z

@cmoulliard I'm working on it, just in case.

cmoulliard · 2020-02-03T21:17:19Z

I hope we don't need to add new properties,

Dont forget then to take care of the filename created by kubernetes ->
old: $HOME/.docker/.dockercfg which is the default on OpenShift and the new: $HOME/.docker/.dockerconfigjson

chanseokoh · 2020-02-03T21:21:44Z

@cmoulliard can you confirm that the actual file for the new format is .dockerconfigjson instead of config.json and you are not guess-working based on how .dockercfg is created?

cmoulliard · 2020-02-04T08:17:41Z

can you confirm that the actual file for the new format is .dockerconfigjson instead of config.json and you are not guess-working based on how .dockercfg is created?

ocp only creates the old config file within the pod -> .dockercfg unfortunately

chanseokoh · 2020-02-07T23:23:28Z

@cmoulliard I installed Tekton on Red Hat CodeReady Containers and was testing the Jib Maven Tekton task. I came to know that Tekton actually provides an auth mechanism to create ~/.docker/config.json. It does work and I can see Jib picks up the file:

[INFO] Using credentials from Docker config (/tekton/home/.docker/config.json) for default-route-openshift-image-registry.apps-crc.testing/tekton-pipelines/test

chanseokoh · 2020-02-25T22:21:26Z

@cmoulliard we've released Jib 2.1.0 with this fix.

chanseokoh · 2020-03-05T23:43:30Z

FTR

Tekton actually provides an auth mechanism to create ~/.docker/config.json. It does work and I can see Jib picks up the file:

This auth mechanism has an issue and I see it may not work in the future.

Phase out overwriting of image's HOME variable. Remove /tekton/home. tektoncd/pipeline#2013 (comment)
TaskRun fails during initialization when disable-home-env-overwrite=true tektoncd/pipeline#2165

can you confirm that the actual file for the new format is .dockerconfigjson instead of config.json

I came to understand how Kubernetes Secrets are exposed when volume-mounted. The filename will be the name of the data items. For example, with the kubernetes.io/basic-auth type like

kind: Secret
...
type: kubernetes.io/basic-auth
stringData:
  username: developer
  password: 5Am4...

the filenames will be username and password (symlinked to ..data/...).

[build-and-push] drwxrwxrwt. 3 root root 120 Mar  5 23:38 .
[build-and-push] drwxrwxrwx. 5 root root  55 Mar  5 23:38 ..
[build-and-push] drwxr-xr-x. 2 root root  80 Mar  5 23:38 ..2020_03_05_23_38_13.868354962
[build-and-push] lrwxrwxrwx. 1 root root  31 Mar  5 23:38 ..data -> ..2020_03_05_23_38_13.868354962
[build-and-push] lrwxrwxrwx. 1 root root  15 Mar  5 23:38 password -> ..data/password
[build-and-push] lrwxrwxrwx. 1 root root  15 Mar  5 23:38 username -> ..data/username

For the Secrets of type kubernetes.io/dockercfg and kubernetes.io/dockerconfigjson, Kubernetes requires that the name of the data item be .dockerconfigjson. For example,

kubectl create secret generic ... --from-file=.dockerconfigjson=...

or

kind: Secret
  ...
data:
  .dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0=
type: kubernetes.io/dockerconfigjson

Therefore, the filename will be .dockerconfigjson.

[build-and-push] drwxrwxrwt. 3 root root 100 Mar  5 23:21 .
[build-and-push] drwxrwxrwx. 5 root root  55 Mar  5 23:22 ..
[build-and-push] drwxr-xr-x. 2 root root  60 Mar  5 23:21 ..2020_03_05_23_21_56.746451257
[build-and-push] lrwxrwxrwx. 1 root root  31 Mar  5 23:21 ..data -> ..2020_03_05_23_21_56.746451257
[build-and-push] lrwxrwxrwx. 1 root root  24 Mar  5 23:21 .dockerconfigjson -> ..data/.dockerconfigjson

chanseokoh mentioned this issue Jan 31, 2020

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

Closed

chanseokoh changed the title ~~Try .docker/.dockercfg if config.json is missing~~ Try .docker/.dockercfg and $HOME/.docker/... too Jan 31, 2020

chanseokoh mentioned this issue Feb 3, 2020

Check additional Docker config file paths ($HOME, .dockerconfigjson, and legacy .dockercfg) #2264

Merged

chanseokoh added this to the v2.1.0 milestone Feb 7, 2020

chanseokoh closed this as completed in #2264 Feb 11, 2020

This was referenced Apr 29, 2020

Gradle Jib - Run as root user? tektoncd/catalog#289

Closed

Docker Credential #2440

Closed

sv3ndk mentioned this issue Dec 18, 2021

Also looks for registry credential files in XDG folders #3532

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

chanseokoh commented Jan 31, 2020 •

edited

Loading

cmoulliard commented Jan 31, 2020 •

edited

Loading

cmoulliard commented Jan 31, 2020

chanseokoh commented Jan 31, 2020 •

edited

Loading

cmoulliard commented Jan 31, 2020 •

edited by chanseokoh

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 •

edited by chanseokoh

Loading

dmage commented Feb 1, 2020

cmoulliard commented Feb 1, 2020 •

edited

Loading

dmage commented Feb 1, 2020

cmoulliard commented Feb 3, 2020

dmage commented Feb 3, 2020

cmoulliard commented Feb 3, 2020

dmage commented Feb 3, 2020

briandealwis commented Feb 3, 2020

dmage commented Feb 3, 2020

chanseokoh commented Feb 3, 2020 •

edited

Loading

cmoulliard commented Feb 3, 2020

loosebazooka commented Feb 3, 2020

chanseokoh commented Feb 3, 2020

cmoulliard commented Feb 3, 2020

chanseokoh commented Feb 3, 2020

cmoulliard commented Feb 4, 2020

chanseokoh commented Feb 7, 2020 •

edited

Loading

chanseokoh commented Feb 25, 2020

chanseokoh commented Mar 5, 2020

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

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

Comments

chanseokoh commented Jan 31, 2020 • edited Loading

cmoulliard commented Jan 31, 2020 • edited Loading

cmoulliard commented Jan 31, 2020

chanseokoh commented Jan 31, 2020 • edited Loading

cmoulliard commented Jan 31, 2020 • edited by chanseokoh 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 • edited by chanseokoh Loading

dmage commented Feb 1, 2020

cmoulliard commented Feb 1, 2020 • edited Loading

dmage commented Feb 1, 2020

cmoulliard commented Feb 3, 2020

dmage commented Feb 3, 2020

cmoulliard commented Feb 3, 2020

dmage commented Feb 3, 2020

briandealwis commented Feb 3, 2020

dmage commented Feb 3, 2020

chanseokoh commented Feb 3, 2020 • edited Loading

cmoulliard commented Feb 3, 2020

loosebazooka commented Feb 3, 2020

chanseokoh commented Feb 3, 2020

cmoulliard commented Feb 3, 2020

chanseokoh commented Feb 3, 2020

cmoulliard commented Feb 4, 2020

chanseokoh commented Feb 7, 2020 • edited Loading

chanseokoh commented Feb 25, 2020

chanseokoh commented Mar 5, 2020

chanseokoh commented Jan 31, 2020 •

edited

Loading

cmoulliard commented Jan 31, 2020 •

edited

Loading

chanseokoh commented Jan 31, 2020 •

edited

Loading

cmoulliard commented Jan 31, 2020 •

edited by chanseokoh

Loading

chanseokoh commented Jan 31, 2020 •

edited

Loading

chanseokoh commented Jan 31, 2020 •

edited

Loading

cmoulliard commented Jan 31, 2020 •

edited by chanseokoh

Loading

cmoulliard commented Feb 1, 2020 •

edited

Loading

chanseokoh commented Feb 3, 2020 •

edited

Loading

chanseokoh commented Feb 7, 2020 •

edited

Loading