kubernetes
Support for different baseOS images
What would you like to be added?
A way to modify baseimage or change the baseos to different distro image? For example: redhat ubi or alpine or ubuntu
Why is this needed?
Being at a financial org, we are RH based and it would be great to have an option to use RH UBI based images for all of dashboard's underlying components.
I'd start with updating the Dockerfile that we are using and checking if it works with RedHat UBI as we haven't tried that. Once you will verify it, if you would be interested we can talk about adding this as an option upstream. We don't have enough time to pick it on our own, as there are some more important things on our roadmap.
To see how we build images see our CD workflow. If you have any questions then let us know.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
I am not sure if this has any real value to us. We are using a super minimalistic scratch image that is basically empty. Is there any good reason why using RH, Ubuntu or alpine would be better? For sure it would be less secure.
I think it's for compliance at gov/financial type orgs. I agree that it will have not much impact though.
Sorry I have been out of this communication for sometime. I understand dashboard might be using scratch image but having an option to chose a base OS would be great. Highly regulated areas like financial institutions will not approve using alpine os based apps although RH OS based images are approved internally only because we are RH shop: https://catalog.redhat.com/software/containers/ubi8/ubi/5c359854d70cc534b3a3784e
I am wondering why the scratch image would not be approved.
From the official page.
This image is most useful in the context of building base images (such as debian and busybox) or super minimal images (that contain only a single binary and whatever it requires, such as hello-world).
As of Docker 1.5.0 (specifically, docker/docker#8827), FROM scratch is a no-op in the Dockerfile, and will not create an extra layer in your image (so a previously 2-layer image will be a 1-layer image instead).
From https://docs.docker.com/engine/userguide/eng-image/baseimages/:
You can use Docker’s reserved, minimal image, scratch, as a starting point for building containers. Using the scratch “image” signals to the build process that you want the next command in the Dockerfile to be the first filesystem layer in your image.
While scratch appears in Docker’s repository on the hub, you can’t pull it, run it, or tag any image with the name scratch. Instead, you can refer to it in your Dockerfile. For example, to create a minimal container using scratch:
There is basically nothing inside of it. Using actual base image such as alpine or redhat in general will be always less secure since it offers an additional layer, shell, and lots of other OS-related features that potentially can be exploited. From what I know scratch and distroless images are considered best practice when it comes to security.
To provide a bit of context, our institution is just stepping into container world. It is just simpler for financial institutions to have a security backed software support like RH in case there are any CVE's to fall back for support and updates. Knowing financial institutions, I think It is easier process to prove this use case. Hence, we are considering licensing self-managed RH Openshift. EKS has also recently launched k8s dashboard UI although we haven't tried it yet with our EKS clusters
It is just simpler for financial institutions to have a security backed software support like RH in case there are any CVE's to fall back for support and updates.
It definitely makes sense for applications that require a base OS image to run. In our case, we do not need any kind of OS-based image. We can use an empty, no-op scratch "image" with nothing but a static binary inside. There is even no shell. It's literally an empty no-op image. You should be using supported RH OS for the machine that actually runs the containers.
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Reopen this issue with
/reopen - Mark this issue as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
