
Kubernetes Security Assessment [pdf] - Tomte
https://github.com/kubernetes/community/blob/master/wg-security-audit/findings/Kubernetes%20Final%20Report.pdf
======
tptacek
This is good stuff.

A nit:

 _Users should not use AES-CBC or GCM for encryption. Secretbox should be the
default mode of storing information and users should be encouraged to use
KMS._

I see where this is coming and agree in spirit, but GCM is actually idiomatic
Go and implemented through the crypto/aead interface, which does about as good
a job as any library at being user-proof.

I too would probably prefer code that used Nacl primitives over Seal/Open, but
I would probably not flag code that didn't.

~~~
yalogin
AES-GCM or even CBC for that matter is not vulnerable/broken. Why did they
recommend Secretbox? Is there an implementation error? I am not talking about
the potential of making mistakes and using platform supported constructs.

Does it make sense to make this recommendation even if the dev did not choose
a vulnerable algorithm and there aren't any issues with implementation?

~~~
bdesimone
In the document they say that AES-CBC is vulnerable to padding oracle attacks,
and AES-GCM uses random nonces and requires key rotation after so many
iterations.

~~~
tptacek
CBC is vulnerable to error oracles if you don't encrypt-then-MAC it properly
(without the MAC it's also malleable, which is a game-over flaw). GCM is
vulnerable to a bunch of its own misuse issues; it doesn't "use" random
nonces, it is conceivably (through not really realistically) unsafe to use
random nonces, and if you screw up nonce handling it blows up worse than CBC
does.

My point is just, these things all have rough edges.

------
raesene9
For me, the largest one mentioned is a known security issue with k8s
architecture, which is the lack of support for certificate revocation.

So anywhere client cert's are used for authN, if one is lost there's no way to
revoke it, short of rolling the whole certificate authority.

when you combine that with the 200k+ Internet exposed Kubernetes clusters,
that's quite a large potential for attack.

The GH issue for this has been open since 2015
[https://github.com/kubernetes/kubernetes/issues/18982](https://github.com/kubernetes/kubernetes/issues/18982)

------
caniszczyk
The Trail of Bits folks also open sourced the code behind their audit:

[https://twitter.com/lojikil/status/1159190646478913536](https://twitter.com/lojikil/status/1159190646478913536)
[https://github.com/trailofbits/audit-
kubernetes](https://github.com/trailofbits/audit-kubernetes)

------
dkhenry
I know the Kubernetes Assessment was the one to make all the news, but the
teams actually audited a bunch of CNCF projects. Here is the one for the
Vitess project

[https://vitess.io/blog/2019-03-12-vitess-security-
audit/](https://vitess.io/blog/2019-03-12-vitess-security-audit/)

~~~
jey
Vitess is

> A database clustering system for horizontal scaling of MySQL

> Vitess combines many important MySQL features with the scalability of a
> NoSQL database. Its built-in sharding features let you grow your database
> without adding sharding logic to your application.

What a quirky project. Is this for folks who started out with MySQL then find
themselves needing to scale out in "NoSQL" style?

> Vitess automatically rewrites queries that hurt database performance.

That sounds scary.

~~~
sciurus
Vitess was created by Youtube.

But they're hardly the only places scaling out MySQL. Facebook and Slack are
two other prominent examples.

~~~
halbritt
Facebook has taken MySQL scaling to extremes well beyond what Vitess offers.

Not sure if that's a good thing.

~~~
pas
And to understand scaling and extremes: FB basically uses RocksDB and/or MySQL
as a low level storage layer for whatever thing they want to. (And on top they
build the clustering stuff, with the particular CAP choices they think is best
for that particular service/purpose.)

------
raesene9
There is a GH issue tracking the findings from the report
[https://github.com/kubernetes/kubernetes/issues/81146](https://github.com/kubernetes/kubernetes/issues/81146)

------
dpedu
> Fix the hard-coded Docker daemon process name. The process name should be
> dockerd instead of docker.

Why is this a security issue? Also, beyond naming convention, why?

~~~
tedivm
It's definitely a bug, not just a convention-

> The container manager used in kubelet checks for docker daemon process
> either via pidfile or process name. While the pidfile points to the docker
> daemon process PID, the dockerProcessName constant stores a docker cli name
> (docker) instead of docker daemon name (dockerd).

They're trying to look up the process by a name the process isn't using.

------
fulafel
I think the HTTP proxy based architecture is just weird and inherently
insecure. Everything would be much simpler and and easier to analyze in a
normal end-to-end scenario.

~~~
gtirloni
I think that's because of the WebSockets support in kubectl so you can tunnel
things, but it's been a long time since I read about it.

------
geggam
Given all of the security issues I am curious who thinks this is production
ready ?

~~~
cj
Not sure why this is being downvoted.

Kubernetes is __5 years old __. This is very, very young for mission-critical
infrastructure management software.

Having a certain level of doubt in young open source projects is responsible,
in my opinion. I'm interested to hear other people's perspective on
production-readiness of k8s for mission-critical applications.

~~~
raesene9
If security got to be the number one concern for whether things were deployed
or not, then sure we could likely take a more conservative view.

However realistically k8s is in heavy deployment in a wide variety of
industries including public sector, financial services, retail, technology ...
and it's clear that this kind of concern is not the primary consideration.

There were banks in the UK (Monzo) deploying k8s almost 3 years ago
([https://monzo.com/blog/2016/09/19/building-a-modern-bank-
bac...](https://monzo.com/blog/2016/09/19/building-a-modern-bank-backend))

~~~
YawningAngel
The tradeoffs Monzo made are not ones that apply to most business. For most
businesses, you have a profitable and sustainable model and you want to
mitigate the possibility that you sink the ship by screwing the pooch on
security or availability.

Monzo, on the other hand, was default-dead, so betting the farm on a
relatively unproven technology perhaps wasn't risking as much. Nobody talks
about the startups that used unproven tech and sank.

~~~
raesene9
I don't think Monzo had to adopt k8s to survive. It's an infrastructure
technology not something which provides a unique advantage from an app.
development perspective.

Also k8s is far from only used in tech companies. the UK home office (not
exactly a startup) were giving talks about their use of k8s in 2016
[https://www.phpconference.co.uk/videos/2016/kubernetes-
home-...](https://www.phpconference.co.uk/videos/2016/kubernetes-home-office/)

------
alexnewman
Seems as though a bunch of nonsense burgers. But then i realized they are all
just low impact

~~~
muricula
There's a nice table with five high security issues. The lack of
authentication within the cluster is pretty damning.

~~~
raesene9
yeah that one is kind of interesting, really needs more detail. I _think_ what
they're talking about is that it's _possible_ to configure insecure
connections between the different components.

However, if that's the case, that's a distribution specific issue and not
really anything intrinsic in k8s.

 __Edit __\- there 's a GH issue here
[https://github.com/kubernetes/kubernetes/issues/81112](https://github.com/kubernetes/kubernetes/issues/81112)

