-
Notifications
You must be signed in to change notification settings - Fork 39.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rebase most docker images on gcr.io/distroless/static #70249
Comments
/sig cluster-lifecycle |
not sure if sig cluster lifecycle is the best owner for this. |
I just hit during a deployment of 1.12, this issue: Please add a sane nsswitch.conf to all the images or convince the golang folks to fix their defaults. |
/assign @ixdy This is not sig-cluster-lifecycle typically. |
before #70245 there was #69238, though that didn't make it into 1.12. cc @BenTheElder |
Yeah, I added an nsswitch.conf as a small stopgap in #69238, but I'd like to see a standard base image as well which should simplify the build and patching a bit. We could backport #70245 or #69238 to 1.12, I'm not sure what the best choice is. #69238 is smaller but #70245 is the preferable change going forward. |
Note that go's defaults actually match the documentation for not having an |
Another option is to just use distroless/base, although it does include a few c libraries that we don't need. |
would distroless/base have what we need for EG the iptables (kubeproxy) variant? |
I don't think so - it doesn't have a package manager so iptables would still need to be manually added (and managed). |
It looks like distroless is planning to put out an image without the c libraries, specifically for this use case. I think we should just use that as soon as it's ready: GoogleContainerTools/distroless#256 |
Update: gcr.io/distroless/static is now available. I suggest we work towards this end-state: All official Kubernetes images & addons are based on 1 of 2 images: For the latter, our current recommendation is Action Items:
I propose we try to tackle 1-3 in Kubernetes 1.14. /milestone v1.14 |
cc @mkumatag (please see 1i from Tim above) |
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 |
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 |
Still needs a review of docs; will work on this during some intercycle downtime |
@justaugustus hi, I'm with the Bug triage team for 1.24 - we noticed that this issue has not been updated for a while. I wonder if there is any work planned or expected that would go into 1.24? Thanks! |
I don't believe there are any further changes in 1.24. Sorry @tallclair I missed your reply #70249 (comment)
I don't think that will be hard at all. Distroless has pretty much the same proposition when using anything beyond "base", e.g. the "static" image has glibc from debian packaging. If we can settle on what information we wish to preserve (or generate!) we should be able to do this, e.g. currently we preserve package copyright info. And presumably distroless either doesn't handle this and leaves us in the same boat with other images, or we can copy what they're doing. I'd have to dig more to see, I think this is
Well, currently I'm using a multi-stage dockerfile but the overall approach can be implemented many ways. Multi-stage dockerfiles can be pinned to pull source images by digest and are relatively hermetic since they're inherently a sandboxed filesystem. If we have any concerns with this, we could also pull the package contents directly and add them to an image. The bazel rules_docker package largely wraps https://github.com/google/containerregistry Bazel is also slightly a moot point for kubernetes following kubernetes/enhancements#2420 |
@tallclair nudged me about this, digging around shows that distroless images persist package versions by putting the package control file in Source: bazelbuild/rules_docker@f5432b8 Scanners already need to implement support for this to handle our other distroless images. (see e.g. aquasecurity/fanal#28) We can very easily grab the package status ( kubernetes-sigs/kind@6957f37 (first commit in kubernetes-sigs/kind#2624) |
I think if we wanted to continue with this approach for the iptables image it would look like:
Then we'd have an image with just iptables binaries, their library dependencies, tzdata etc. from distroless base, their copyright files, and their dpkg statuses, along with some symlinks and a go binary for switching between iptables-legacy and iptables-nft. That image should be smaller and have less vulnerability scanner alerts. Step 1) is probably reasonable to consider regardless of step 2) anyhow, if someone wanted to take this up. You'll need to talk to SIG Network about these changes first though. This new image would also be a breaking change for any other projects that base on debian-iptables. |
/milestone v1.25 kick this down the road, no activity. |
Hi @tallclair! |
@dims @tallclair 👋 the release 1.25 bug triage Lead. I'm reaching out to see the status of this Issue and if we are still targeting the current release. |
Heya @dims and @tallclair - 1.26 bug triage team checking in to see how we're looking for this release? Thanks! |
@salaxander the last thing we wanted to do here was distroless kubeproxy which got done already.
We should close this out! thanks everyone! |
@rikatz Do you mind doing a quick update to https://github.com/kubernetes/enhancements/blob/master/keps/sig-release/1729-rebase-images-to-distroless/README.md and https://github.com/kubernetes/sig-release/blob/master/release-engineering/baseimage-exception-list.md to reflect the fact that we now have kubeproxy with distroless images? thanks! |
We should probably still make distroless kubeproxy lighter and make sure our projects pick it up so we can phase out the old full image, do we have follow-up issues for getting the shell etc out of there and making sure we've rolled out the image to subprojects? |
EDIT (from @justaugustus - 5/8/20):
go-runner
(distroless++) (@dims)go-runner
image -v0.1.0
go-runner
tov0.1.1
go-runner:v0.1.1
imageDebian base images (
debian-base
,debian-iptables
) andpause
(@justaugustus)debian-base
imagedebian-iptables
imageForked from #40248 (think of this as V2).
scratch
is not quite sufficient as a base image for static go binaries. Common dependencies include ca-certificates, resolv.conf, hosts, and nsswtich (see #69195). See below for a more complete list.We need to decide if we want a scratch+config base image (either found or created by us), or a more complete distro (e.g. debian-base, at the cost of more frequent patching).
gcr.io/distroless/static
has also been proposed, or could provide inspiration for a static base.Blocked by: (for the scratch case) #61006, for logs redirection.
/kind bug
/cc @ixdy
Appendix
Here is a list of
/etc/*
files referenced from the go source (obviously some of these are not applicable):The text was updated successfully, but these errors were encountered: