Support Private Registries

[ncresswell]

In the alpha, images could only come from public/open registries. In reality, this would be uncommon in production environments, so we need to support the ability to do a "docker login" at deployment time based off the image pull secret provided in the application manifest. We should not hold this on disk, it should be used solely at deploy time.

[deviantony]

To avoid storing registry credentials as clear text on disk, we can utilize the fact that secrets used for registry authentication are of the kubernetes.io/dockerconfigjson type. By detecting when a secret of this type is created, we can store it inside an in-memory map.

However, this approach has a limitation. The secret would need to be recreated each time the k2d server is restarted.

We'll start by supporting the creation of a secret that leverages an existing config.json:

kubectl create secret generic regcred1 \
    --from-file=.dockerconfigjson=/home/user/.docker/config.json \
    --type=kubernetes.io/dockerconfigjson

And potentially support the following method to create a registry secret:

kubectl create secret docker-registry regcred2 \
    --docker-server=https://index.docker.io/v1/ \
    --docker-username=deviantony \
    --docker-password=password \
    --docker-email=anthony.lapenna@portainer.io

[m0ssc0de]

If support k8s CRI, the ImageService may be useful. If only consider secrets when deploying, in-memory map should be enough.

[ncresswell]

as long as secrets are re-presented to docker for image pulls on deployment updates, then all good for it to be in memory.. as there is no cluster, images are already on the hosts, so a host restart would still just see docker restart the container using the cached image.