Distroless images #1729
Comments
|
@justaugustus: The label(s) In response to this:
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. |
k8s-ci-robot
added
the
sig/release
|
/committee product-security |
k8s-ci-robot
added
the
committee/security-response
|
/assign Spoke w/ @tallclair earlier and I'm going to take this one over since @dims and I have been making some forward progress here, tracked in kubernetes/kubernetes#70249 + kubernetes/kubernetes#58012 and some other threads that I need to tie together. cc: @yuwenma @dekkagaijin @palnabarun -- This is going to require an exception, which I'm not quite ready to file, but will next week. Just putting it on your radar in the meantime... /milestone v1.19 |
k8s-ci-robot
added
the
stage/beta
|
@justaugustus -- Thanks for the ping! 👍 I have added this enhancement to the tracking sheet and noted that an exception would be filed in the very near future. I'm assuming this is the KEP for this enhancement. |
|
Are we using these images because we think that they're better? What makes them better? The KEP seems to just say "thinner and lighter" and mumbles about attack surface. Do we actually have real problems we're trying to solve here? Forgive me if I missed some discussion that can be pointed to about this, the PR about the KEP didn't seem to have any of that... |
|
Motivations:
|
|
@tallclair Honestly, if they own the image, they own the kubelet. If all your stuff lives in Kubernetes, I think it's pretty much game over anyway. |
|
Erk, I mean if they own the kubelet (the actively running thing in the image), then it doesn't matter. It's game over, and what else your image has doesn't matter. |
|
That does not and should not deter us from making efforts to ensure the images are more secure. |
|
Sure, but I still don't see how "distroless" images do that. Part of my skepticism comes from having looked into how those images are built. It's hard to trust images that just download and inject goop into the image that would be hard to reliably audit in the first place. 😉 |
|
@Conan-Kudo can you please give a specific example in kubernetes/kubernetes that you are uncomfortable with? |
|
It's not bad at the k8s level. My problem is mostly with how the actual base images are constructed. The "fetching and installing packages while not respecting dependencies" and the occasional "fetching and injecting from the internet" means that it's hard for me to trust it. It may be fine for k8s, given that most of it is in Go, but the inherent broken dependencies thing in distroless images makes me wary. |
|
The above also worries me for another reason: they chose Debian as the base of distroless, and yet continue to hacksaw it instead of working in Debian to fix things. I personally favor Fedora for my stuff, but when I find issues with images being too big in Fedora, instead of doing hacksaw maneuvers, I actually go and try to fix it in Fedora itself. The distro even has a minimization project to cut down the dependency web for containers to the absolute bare minimum when desired. In my view, this is the right approach to solving this problem. A Fedora variant of "distroless" would actually be ~40MB, based on their own tooling with no hacks. |
|
"they chose Debian" .. you are talking about https://github.com/GoogleContainerTools/distroless/search?q=stretch&unscoped_q=stretch ? @Conan-Kudo you can and should have your own CI/CD pipeline with your own images if you are doing anything meaningful and not rely on someone else's image. period. If our k8s makefiles/dockerfiles do not support it, then please report a bug and we will fix it. AFAIK, all our plumbing allows injecting base images of your own. So please do that. |
|
@dims Yes. And of course, I have my own pipelines for making images. I'm not lazy. 😉 But this is why I brought up the Fedora example. Because of the work by @asamalik and others, I have been able to make really tiny images in my own pipelines without hacksaw techniques, and that means the images are much easier to verify, validate, and audit. 😄 And while the tooling allows injecting my own base for this, defaults matter. Lots of people don't change a thing here, and that's why I'm talking about this at all. |
|
@Conan-Kudo i'd request you to follow this up with an issue in GoogleContainerTools/distroless since you are worried about the techniques they use. If this is a request for kubernetes to switch over from those images to something else, we need to file a KEP to discuss options/possibilities etc. It's going to require a community decision and KEP's are the way we do it. |
|
I have no illusions that the GCP team would care about what I think. I may consider filing a KEP, once I'm a little more comfortable with my understanding of the process. |
|
@Conan-Kudo I think your concerns may be with the distroless images in general, but maybe aren't applicable to the distroless:static image that we're actually using. The static image doesn't have any executables or libraries, and therefore doesn't have any dependencies that can be broken. It is meant as a base for statically compiled binaries only (no dependencies). |
|
@tallclair Perhaps, it'd also depend on how the Go compiler was sourced, but that does go quite a long way to alleviate issues... In general, I think the distroless images are a poor choice for reliable containers (for the reasons I outlined above), but naturally it's possible to mitigate those... |
LappleApple
moved this from In progress
to In Progress, but no activity in >=14 days
in SIG Release
Rebasing the k8s images to distroless/static can make the images thinner, safer and less vulnerable. Meanwhile, it will drastically reduce churn on the total number of k8s images versions. Due to the fact that many images are based on debian base and a vulnerability in debian base (a couple times a month) will result in rebuilding every image, changing the image from debian base to distroless/static can reduce the total number of k8s image versions. See: https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/1729-rebase-images-to-distroless kubernetes/enhancements#1729
|
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
lifecycle/rotten
|
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
|
@k8s-triage-robot: Closing this issue. In response to this:
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. |
|
Distroless kube-proxy base image is in-progress. |
BenTheElder
removed
the
lifecycle/rotten
|
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
Distroless kube-proxy shipped in 1.25 |
|
/remove-lifecycle stale |
k8s-ci-robot
removed
the
lifecycle/stale
|
/milestone clear |
|
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
/remove-lifecycle stale |
k8s-ci-robot
removed
the
lifecycle/stale
|
We actually finished this in 1.25, the KEP needs updating. |
Atharva-Shinde
removed
the
tracked/no
|
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
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:
You can:
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:
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. |
Enhancement Description
distroless/staticPlease to keep this description up to date. This will help the Enhancement Team track efficiently the evolution of the enhancement
Will update. Tracks kubernetes/kubernetes#70249.
/area security
/sig release
The text was updated successfully, but these errors were encountered: