top | item 18717603

Let Google do the patching with new managed base images

120 points| cimnine | 7 years ago |cloud.google.com

70 comments

order
[+] dlor|7 years ago|reply
I'm Tech Lead/maintainer for these images. Happy to answer any questions!
[+] JaimeThompson|7 years ago|reply
Will it be 18 or 24 months before Google discontinues this product offering? How long will customers who chose to use this offering have to move to another solution once Google discontinues it?
[+] Operyl|7 years ago|reply
Why is 18.04 not an available-at-launch image choice?
[+] drewda|7 years ago|reply
What do you all think of Cloud Native Buildpacks?* A slightly different approach to solving some of the same problems of handling dependency and security updates off-cycle from application updates.

* https://buildpacks.io/

[+] alwaysdoit|7 years ago|reply
What's the difference between this and say:

FROM ubuntu:16.04

Won't that pull the latest official Ubuntu image with that tag?

[+] rdsubhas|7 years ago|reply
Hi, you have covered base images vs distroless images in your article.

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)?

[+] yanslookup|7 years ago|reply
Is there a dockerhub like interface where I can see all of the repos and available tags? I clicked several links in the blog but didn't see anything similar.
[+] philip1209|7 years ago|reply
I'm trying to understand the value proposition here. Is it:

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?)

[+] dmoy|7 years ago|reply
What's the difference between these and say launcher.gcr.io/google/ubuntu16_04? (aside from not being pinned)
[+] Someone1234|7 years ago|reply
Do you think this strategy could be successful/have a future for non-container based Operating Systems?
[+] rob-olmos|7 years ago|reply
"The CentOS managed base image uses `yum` and `rpm` for package management, and these pull RPM files only over HTTPS connections."

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.

[+] TurningCanadian|7 years ago|reply
a MITM can trick your server into thinking there are no updates, and no error will be raised
[+] coder543|7 years ago|reply
The Ubuntu base image is Ubuntu 16.04, which is an interesting choice. 18.04 LTS has been out for awhile now, so I would have expected it to at least be an option.
[+] dlor|7 years ago|reply
Whoops, that looks like an oversight. 18.04 is definitely available as well.
[+] paaaaaaaaaa|7 years ago|reply
What's the difference between this and pulling an official image from dockerhub? For example https://hub.docker.com/_/ubuntu/
[+] LaGrange|7 years ago|reply
It's betting that Google are better package maintainers than Debian/CentOS/Ubuntu, especially when it comes to maintaining container images. From a purely technical, and financial, point of view, it's likely true.

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.

[+] nad7vx|7 years ago|reply
This is awesome - is there any thing similar for Azure? Or possible 3rd party solutions that do the same? We don’t leverage GCP but I am very envious of this feature. Would love the community to help point me in the right direction to get same functionality - mainly not having to maintain and patch Ubuntu 16.0.4 images
[+] TheIronYuppie|7 years ago|reply
The good news is you don't have to use GCP! The very nice people over there have made them available for anyone -

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"
This should work fine.

Disclosure: I work at Microsoft on Azure.

[+] fatherlinnux|7 years ago|reply
Yeah, it's called Red Hat Enterprise Linux ;-) It's available on all the cloud providers and has a better API/ABI guarantee as well as very, very well defined commitments to patching and lifecycle :-)
[+] stefan_|7 years ago|reply
I think they call it "serverless"
[+] tmdk|7 years ago|reply
Does Google (or any of the other cloud vendors) audit/review the actual source code of packages used in the images? such as apache, nginx, openjdk, etc? or do they just run a scanner that test for known vulnerabilities?
[+] jiveturkey|7 years ago|reply
wow. why would anyone want this? in a production environment you want tight control over software versions, not surprise updates.
[+] jacques_chester|7 years ago|reply
I generally agree with you. However I also feel that the ABI guarantees by Red Hat, Canonical and the Debian project are fairly trustworthy. Rolling forward automatically is much less risky, taken overall, than a rotting pin.
[+] LaGrange|7 years ago|reply
"Let Google do the patching"

Also replace your shepherd dogs with wolves, wolves are bigger, faster, and will do it for free[*].

[+] seccess|7 years ago|reply
I don't understand this comment, what are you suggesting Google will do? Surreptitiously insert code into your binary during a patch?

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?

[+] andybak|7 years ago|reply
This doesn't make any sense. What motives would Google have for providing an insecure service on their cloud hosting.

I'm all for Google-bashing in areas that actually make some sense but this is nonsensical.