This is a first pass at being able to use image pull secrets created with kubectl. It's not perfect (I think docker's config.json allows you to specify different creds for the same repo URL at different paths) but it's a decent start.
The first case creates a secret detailed here: https://github.com/elotl/kip/issues/96
The second case creates a secret with the entire contents of /home/myuser/.docker/config.json base64 encoded. For that case, the docker server can either be a hostname (e.g. 689494258501.dkr.ecr.us-east-1.amazonaws.com) or a full url (https://index.docker.io/v1/).
This PR tries to understand both formats do work to extract the correct server credentials, either from the username and password fields or falling back to the auth field. It's possible we could just use the auth field... I'm unsure if we should be defensive or make that simplification.
K8s docs for image pull specs are here: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
This is a first pass at being able to use image pull secrets created with kubectl. It's not perfect (I think docker's config.json allows you to specify different creds for the same repo URL at different paths) but it's a decent start.
Creating docker secrets:
The first case creates a secret detailed here: https://github.com/elotl/kip/issues/96 The second case creates a secret with the entire contents of /home/myuser/.docker/config.json base64 encoded. For that case, the docker server can either be a hostname (e.g.
689494258501.dkr.ecr.us-east-1.amazonaws.com) or a full url (https://index.docker.io/v1/).This PR tries to understand both formats do work to extract the correct server credentials, either from the username and password fields or falling back to the auth field. It's possible we could just use the auth field... I'm unsure if we should be defensive or make that simplification.