Let Google do the patching with new managed base images
cloud.google.com
cloud.google.com
FROM ubuntu:16.04
Won't that pull the latest official Ubuntu image with that tag?
- If you're running on GCP, pulling images from GCR will likely be much faster than Dockerhub given network locality.
- Content Trust. DockerHub images are maintained by a large team of upstream maintainers and volunteers. These images are fully managed by Google, and you can examine and audit the full supply chain from source to built image.
* Faster fetch - not a big deal IMO (edit: you could just mirror, you don't have to do the patching)
* Content trust - but trust to e.g. Canonical's Ubuntu is required anyway, right? And then, you have to trust Google.
Examples of reasons I would take as good:
* Does Google routinely do audit of original distro images, so that it's less of a risk to use community distro like Debian? It could.
* Is Google "manning" the work on the actual distributed software, accepting users' bugreports and then working with upstream to fix it? It could.
Even-more-downstream-distro is actually not a bad idea.
At best such a comment is completely ignorant of the existing ecosystem.
--- edit add disclosure statement
Disclosure: I work at Microsoft on Azure, previously at Docker on the core engine.
But, there's nothing to say that the upstream distro would accept the changes. Google has more stringent requirements that a general distro, and you're choosing to follow those requirements (at the benefit of Google's automated scanning). It's totally your choice.
Disclosure: I work at Microsoft on Azure.
If upstream didn't accept it, then it shouldn't be masquerading as what upstream is... which is what changing `FROM $image` to point to Google's image does.
> and you're choosing to follow those requirements
From what I gathered from the article, Google is changing the meaning of `FROM $image` to mean Google's build of the image. There is no choice in the matter outside of using Google's services.
Disclosure (and sorry for not mentioning in the original comment, I've updated): I work at Microsoft on Azure, and formerly at Docker on the core engine.
These also happen to be the ones that have been in use by some of our "more serverless" offerings, where users don't get to supply a Dockerfile, for some time now.
I read this perhaps the wrong way, in which case I apologize on that front.
Today, these images are already safer than other images
or
In the future, these images have an SLA for updates and patches in case of future problems
(or, both?)
It's 2018 and dockerhub _still_ doesn't have 2FA. All it takes is one cred-stuffed account belonging to a debian maintainer to take you down if you don't pin your images.
Thanks!
From there you can go up a level to see all images in the /google/ namespace: https://console.cloud.google.com/gcr/images/cloud-marketplac...
A lot of organizations don't yet have the tooling required to maintain distroless images (since that tooling extends all the way to developer machines).
Have you considered a hybrid option, where in GKE, you automatically keep this base image layer auto-updated when running on cos? It could give organizations that don't have distroless capability to still use vanilla docker tooling, but still get the same benefits of distroless at runtime (and potential of increased adoption it might drive to GKE)?
They maintain official RHEL-based images available on their own catalog [1]
Some images are "s2i" (Source-to-Image) which are automatically built by merging a vetted base image and source code from a git repo [2].
[1] https://access.redhat.com/containers/
[2] https://docs.openshift.com/container-platform/3.11/architect...
I work for Pivotal. We have a contract with Canonical that leads us to base all our work on Ubuntu, including derived base images, analogous to how RHEL is bundled into OpenShift.
If you're buying from us, this news is neutral. If you're buying from Red Hat, this news is neutral. If you're buying from neither, it's good news.
I think these images will fold up neatly into CNBs without much fuss, if they are packaged as stacks.
That's interesting. Is there a reason for that?
IIRC the stock CentOS doesn't use HTTPS for its yum/rpm repos and I figured it wasn't necessary to use HTTPS since the package signature is verified.
Of course, they could have bolstered the distro teams. And the fact that the repositories are within GCR, not Docker, is just convenience.
It brings you closer into Googles warm, technototalitarian embrace, is what I mean.
They've been at it (looks like) since ~2014, and their goals and motivations seem 100% in line with google, but at the package/distro level, not the container-base-image level (highly related): https://tests.reproducible-builds.org/debian/unstable/amd64/...
It's been a long time since I've believed in their idealism, yes, but I still think accusing Debian of being in the advertising and surveillance business is a bit harsh.
My intent was to challenge your statement that google are better package maintainers than Debian, specifically w.r.t. reproducibility of builds.
It's disrespectful to Debian to think that they haven't been pushing for secure, auditable, trusted software running on trusted computers.
It's practically their reason for existing: taking open, auditable software, packaging it in reproducible fashion for use by anyone who wants it.
https://www.debian.org/social_contract.html#guidelines
Imagine if Debian had similar financial support available compared to Google/RedHat? The best info I could find is here: https://www.spi-inc.org/corporate/annual-reports/2017.pdf
`This covers the Period January 1, 2017 – December 31, 2017`
`Gross Income -------- 635,311.59`
...and in that way, yes: google can afford more package maintainers, more scrutiny, but if they are "better package maintainers" it's at those margins and due to economics rather than ability or desire.
Ah, I believe there's a misunderstanding coming from misreading of my statement: what I wrote is that the _reason to upgrade_ would be the _belief_ that they are better, and that if you restrict yourself to _certain measures_, they probably can, by throwing more money at the problem. I hoped that he latter part of my comment probably makes it rather clear that Google wouldn't actually be better as far as I'm concerned. Even from purely technical perspective, I'm fairly sure Debian is willing to support many architectures Google will ignore.
This is difficult with Docker directly today because timestamps appear all over the place. We designed and built a custom set of bazel rules to make this possible.
(I work on GCP)
https://cloud.google.com/container-registry/docs/managed-bas...
So, to be clear, no matter what cloud you use, if you create a Dockerfile like the following:
FROM launcher.gcr.io/google/ubuntu16_04:latest
CMD echo "foobar"
Disclosure: I work at Microsoft on Azure.
Thanks!
Also replace your shepherd dogs with wolves, wolves are bigger, faster, and will do it for free[*].
I'm all for Google-bashing in areas that actually make some sense but this is nonsensical.
If you are running in Google cloud, its their machines and they have power to do pretty much whatever they want anyway. How would this feature affect anything?