Hacker News Reader

Comment by whalesalad | Hacker News Reader

Got in a pretty heated debate with a colleague once about this. We had a really great infrastructure setup with a VPN bastion host that would get you into our VPC. You couldn't reach any of our kube nodes externally. Your Google account was your VPN account. It was pretty solid.

When this engineer redid things they opted to go the public internet route where the master runs a public api and auth is done via a certificate. The logic here was so that external 3rd party stuff (CI) could control our master.

To my knowledge this setup is still running and chances are these machines are vulnerable to this issue.

Contrast to the prior setup where, immediately upon being offboarded from the company your VPN access became automatically terminated (thank you LDAP and Foxpass!)

View on HN

I can't imagine a good reason to expose ANY of my services to the public internet. Aside from a rest-api that drives our application, where that is the feature of course.

With software like google IAP, and many similar products, it just seems silly.

May I recommend reading up on beyondcorp [0]?

Google has moved its internal stuff to the beyondcorp model, and it honestly seems like a better approach if you really care about security and have a big enough security team to make it work.

[0]: https://www.beyondcorp.com/

Beyondcorp is a great model IF you can afford to manage it correctly.

Google have a) huge resources and b) a threat model which means they're subject to a lot of high-end attacks all the time.

for many corp's the idea of exposing all their services and endpoints to the general internet without firewalls or VPNs would ... end poorly...

Thank you for the suggestion! :)

Google I(dentity)A(ware)P(roxy) is actually a hosted beyondcorp implementation! But I probably should have explained that in my original comment.

No, a Kube cluster with client certificate authentication enabled is not going to be vulnerable to the specific issue discussed in OP's blog post: those are Kube cluster exposed publicly with no authentication whatsoever.

I generally think it's no more risky to expose a Go app with cert-based auth than it is to expose OpenVPN so long as both are set up correctly.

Actually the CVE mentioned at the top of the blog could be exploited over the API server port in quite a few default configurations (thus the CVSS 9.8 score)

Many Kubernetes distributions enable anonymous authentication to allow for health checking, so there is some risk there.

As to the general point, the only thing I'd say is that Kubernetes is a massive 1.5 million Line code base which is relatively new code, where Openvpn has been around and attacked for a long time. I wouldn't be surprised if the recent CVE isn't the only issue we see in k8s over the next year.

Why is a web server's demand for a certificate different from a VPN server's demand for a certificate?

Because VPNs are magic that never has a backdoor for a decade.

Complexity and publicity.

Complexity: Single purpose apps built with a very specific threat model in mind for a boring, established usecase tend to be more secure. K8s is a fast evolving labyrinth of complexity with contributions from thousands of people, very few of whom have a grasp on the whole codebase.

Publicity: the general Internet doesn't find your VPN server just by using your API.

The VPN server offers frivolous features like session tracking, and certificate revocation. Things k8s continues to punt down the road or outright ignore.

> The logic here was so that external 3rd party stuff (CI) could control our master

Why not sidestep the issue by running CI within the VPC? :/

Ugh going from bastion host hopping to publicly addressable would be a nightmare. Please tell me the database doesn't have a publicly addressable ip & host.

Bah I hope they at the very least have firewall whitelist rules to limit API access to your CI vendor ranges.

A the risk of stating the obvious: using a VPN would not really protect you this vulnerability, though it would mitigate your exposure (a lot or a little depending on your setup and threat model).

edit: to clarify, vpn/vpc requirement would turn CVE-2018-1002105 from a pre-auth to a post-auth vulnerability, right? Which might be a big or small help depending on how controlled your user pool and signup process is.

Reply on news.ycombinator.com