-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Changes to container images. #4054
Comments
Best: 1 |
Any way we could find out what customers install on top of our image? My (naive) thinking was: image's API are its entrypoint, ports, env vars and volumes. Base image and other binaries available within are not, unless you specifically create an image intended to be base for others. But I agree that the current situation is confusing for anyone using teleport as base image. We can keep the status quo (ubuntu base), but I'd like to better understand how we ended up maintaining a base image for others.
Which means that our latest patch release tag is mutable, right?
This is something we should be verifying by hand for every CVE and explaining to customers scanning their images. |
Just to add some background. The only way I've ever seen a major.minor tag used is to point to the same image as the latest major.minor.patch tag. If strictly following semver, it should always be possibly to pull on major.minor without creating conflicts, and then if necessary can lock into a specific patch. You can see this with golang for example on docker hub, look at the shared tags: https://hub.docker.com/_/golang or quay.io shows this as a link between tags: https://quay.io/repository/gravitational/wormhole?tag=latest&tab=tags (I messed up the publishing of 0.2, but can be seen with 0.1 or 0.3) Also the historical context on ubuntu vs alpine which lead to preiously recommending ubuntu in the teleport containers, is historically the vulnerability scanners weren't able to scan alpine images and would produce clean scan results even though they didn't really scan the image. While clair (the scanner used by quay.io) does now seem to support alpine images, I have no idea if the backend vulnerability databases are as accurate (could be less, the same, or more accurate, I have no data). Musl is also a consideration, while I realize there are lots of reasons to want to use musl, I've personally found it to be a frustrating experience, specifically users with issues with the DNS resolver, when running in kubernetes, etc. So supporting it might mean supporting the OS as well when someone deploys it and encounters issues. On the gravity side, we use alot of our custom debian minimal image, but in most new cases are standardizing on ubuntu or distroless, and we want to use more distroless where possible. I don't think distroless works in this case, since I believe the docker image ships tctl, and expects a user can get a shell in the container to run tctl commands (as opposed to just execing tctl individually for each command). In almost all cases, I've seen ubuntu on the latest .10 release produce the cleanest scan results, and it is a good / standard distribution for containers, with Canonical security team backing it like they do with Ubuntu. Edit: just to clarify, latest ubuntu .10 release being like 20.10 should scan pretty clean, with 18.10 for example beginning to accumulate medium/minor vulnerabilities. Although there is a single high vulnerability that seems like it's in a wontfix state that keeps popping up in our gravity scans which will likely never be executed. |
I agree, @jon-can can you share some more information with us.
Our latest patch should still have been built with Ubuntu.
I'm not against this, just don't think we should break existing workflows. I have no problem with 4.3-alpine or (4.3-distroless) maintained in parallel and even our documentation recommended them when appropriate. |
@awly Our The
@knisbet Yeah - we essentially worked around this by using an
@knisbet For context, using
@russjones My argument would be that we haven't broken anyone's workflow at all. If someone was using The idea behind the mutable Fix-wise, I think we should probably change the I can also make a change to rename the existing images to |
@russjones @webvictim sorry, I left a confusing comment about mutability.
|
I think that @russjones was just referring to changing the |
In #3357, we introduced a new image tag
major.minor
in addition to the existingmajor.minor.patch
images. For example4.3
and4.3.0
. The idea is that4.3
would be rebuild nightly and have the latest patch version and be mutable but4.3.0
(and all other patch releases) will be immutable and might have a somewhat stale base OS.One of the main drivers for this was to keep the container image patched against security vulnerabilities.
Along with this change, we also switched the base OS to alpine instead of Ubuntu. The reason to switch to alpine was to reduce the image size as well as reduce the attack surface of the image.
This has lead to multiple customers complaining that they've now had to update their Dockerfiles because
apt-get
no longer works. This is very reasonable for an outside observer that does not have the context of the discussion in #3357, it's not clear why the base OS would change between tags that Gravitational publishes.@knisbet has suggested that instead of creating a brand new image for each
major.minor
image, instead just update that tag to point to the latestmajor.minor.patch
release.My suggestion is we drop support for alpine (by switching to Ubuntu) for the
major.minor
releases, but keep everything the same (keep the nightly rebuild of images). My reasons are:major.minor
tag to the latest patch release, if our patch release gets a little old and CVEs will start to show up which means we will not have solved the problem we set out to solve in Keep Teleport base images updated. #3357.We can revisit maintaining another set of images of either alpine or distroless in either 4.4 or 5.0.
The text was updated successfully, but these errors were encountered: