
Let Google do the patching with new managed base images - cimnine
https://cloud.google.com/blog/products/containers-kubernetes/exploring-container-security-let-google-do-the-patching-with-new-managed-base-images
======
dlor
I'm Tech Lead/maintainer for these images. Happy to answer any questions!

~~~
Operyl
Why is 18.04 not an available-at-launch image choice?

~~~
stingraycharles
I think Ubuntu 16.04 is used internally a lot with Google, as they have
hardened it themselves. I believe GKE On-Prem will also be based on Ubuntu
16.04 for this reason.

~~~
ssambros
Not that much anymore. [https://www.zdnet.com/article/google-moves-to-debian-
for-in-...](https://www.zdnet.com/article/google-moves-to-debian-for-in-house-
linux-desktop/)

------
rob-olmos
"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
a MITM can trick your server into thinking there are no updates, and no error
will be raised

~~~
skj
That, and an attacker could do a replay attack, and potentially send you to an
earlier (vulnerable) version.

------
coder543
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
Whoops, that looks like an oversight. 18.04 is definitely available as well.

------
paaaaaaaaaa
What's the difference between this and pulling an official image from
dockerhub? For example
[https://hub.docker.com/_/ubuntu/](https://hub.docker.com/_/ubuntu/)

~~~
LaGrange
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.

~~~
ramses0
I would suggest you look a little deeper into Debian's history and work on
reproducible builds:
[https://wiki.debian.org/ReproducibleBuilds](https://wiki.debian.org/ReproducibleBuilds)

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/...](https://tests.reproducible-
builds.org/debian/unstable/amd64/stats_pkg_state.png)

~~~
LaGrange
> goals and motivations seem 100% in line with google,

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.

~~~
ramses0
> Google are better package maintainers than Debian

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](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](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.

~~~
LaGrange
> My intent was to challenge your statement that google are better package
> maintainers than Debian, specifically w.r.t. reproducibility of builds.

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.

------
nad7vx
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
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...](https://cloud.google.com/container-registry/docs/managed-base-images)

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.

~~~
puzzle
You moved to MS?!? Your about section still mentions your Google address. Good
luck!

~~~
TheIronYuppie
Whoops! Updated :)

Thanks!

------
tmdk
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
wow. why would anyone want this? in a production environment you want tight
control over software versions, not surprise updates.

~~~
jacques_chester
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
"Let Google do the patching"

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

~~~
seccess
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?

~~~
LaGrange
Once you're dependent on their packaging process, why would they ever have to
introduce whatever tracking or restriction they want "surreptitiously"? It'll
be a part of their internal monitoring and diagnostics package.

