Minikube: Reason for the Hard-Coded baseImageSHA

[Eduard-Voiculescu]

Hi,

I was wondering what is the reason for the hard-coded baseImageSHA at this line?

When trying to run minikube start --driver=docker, I get that minikube is trying to fetch the image
gcr.io/k8s-minikube/kicbase:v0.0.10@sha256:f58e0c4662bac8a9b5dda7984b185bad8502ade5d9fa364bf2755d636ab51438. However, if there is a security issue with the image (highly doubt it, but let's assume the worst), wouldn't it mean that when starting minikube with the docker driver every minikube executable under v.1.10.0 will pull a security vulnerable image ? Or even worst, if the image is taken out of the google cloud registry (for obvious security reasons), won't all the minikube executables stop working as the sha256 of the base image changed ?

Best,

Eduard VOICULESCU.

[afbjorklund]

You can pick a different image (with the --base-image parameter), when starting minikube:

--base-image='gcr.io/k8s-minikube/kicbase:v0.0.11@sha256:6fee59db7d67ed8ae6835e4bcb02f32056dc95f11cb369c51e352b62dd198aa0': The base image to use for docker/podman drivers. Intended for local development.

[
    {
        "Id": "sha256:e3ca409c7daffcae553f1a08bbea0306b5c106a9b80fcdd86783ff315cc4c59e",
        "RepoTags": [
            "gcr.io/k8s-minikube/kicbase:v0.0.11"
        ],
        "RepoDigests": [
            "gcr.io/k8s-minikube/kicbase@sha256:6fee59db7d67ed8ae6835e4bcb02f32056dc95f11cb369c51e352b62dd198aa0"
        ],
        "Parent": "",

Or even worst, if the image is taken out of the google cloud registry (for obvious security reasons), won't all the minikube executables stop working as the sha256 of the base image changed ?

This is correct, using the repo digest stops us from re-issuing another v0.0.10 image. I'm not sure if that was the scenario that @medyagh was trying to avoid when using both the tag and the digest?

For the ISO we download the checksum from the same URL as the image, so there it could be re-issued. But if we do another manifest for the KIC, then the manifest checksums would not match (as said)

--iso-url=[https://storage.googleapis.com/minikube/iso/minikube-v1.12.2.iso,https://github.com/kubernetes/minikube/releases/download/v1.12.2/minikube-v1.12.2.iso,https://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/iso/minikube-v1.12.2.iso]: Locations to fetch the minikube ISO from.

$ curl https://storage.googleapis.com/minikube/iso/minikube-v1.12.2.iso.sha256
c993e057d3ee7e1ea71b3c3dc2cba9de0e2f97bbe078ac8efd9f8d40db2ddfba

[priyawadhwa]

Hey @Eduard-Voiculescu so we typically include both tag and digest so that in case the tag is reassigned incorrectly to a new image, users won't be downloading something we didn't intend them to download.

In this case, minikube would indeed stop working without the --base-image flag passed in...it's kind of a tradeoff between that and users downloading a potentially corrupted image.

[tstromberg]

The TL;DR is that we don't update images for older releases of minikube: to address security issues, you'll need to upgrade to the latest minikube.

[medyagh]

also we do not support providing update to the already released minikubes, we just suggest upgrading to the newest minikube verison

[Eduard-Voiculescu]

Thank you all for taking time to respond to this issue. The --base-image is perfect for my use case. Take care!