Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why the hell is your Kubernetes API public?

leebriggs.co.uk

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Why the hell is your Kubernetes API public?

#31

Post by arrakeenrevived »

weikju wrote: post #24
vbezhenar wrote: post #7

It is public, so what? Obviously cloud operators consider it secure enough to offer that option by default. What are the reasons to consider it not secure?

While I agree is likely secure enough, remember that cloud operators such as Aws used to be ok with making s3 buckets public by default, which did cause many issues until they finally changed that (and made it harder to make them public even intentionally).

S3 buckets have never been public by default. They were, however, very easy to make public before things like Block Public Access existed, so lazy devs would just click that button rather than doing proper access control.

Re: Why the hell is your Kubernetes API public?

#32

Post by Repulsion9513 »

maxcoder4 wrote: post #16
xg15 wrote: post #15

I think something doesn't quite add up in OP's claim. Having full access to the control plane effectively let's you do anything you want with the cluster. If there were really millions of completely unsecured Kubernetes instances lying around, we should see all kinds of worms and botnets already taking advantage of them - and we should also see lots of attempted probes/attacks to infect new instances as soon as they…

Of course that's how it works, there are various authentication methods that must be completed [2] to do anything. The author's claim is that similarly like you shouldn't expose RDP to the public internet, you shouldn't expose your k8s API. In practice the difference is that while RDP (or database or WordPress) credentials are vulnerable to bruteforce, in almost all cases k8s clusters are secured by either mtls or jw…

In practice, no one's actually bruteforcing your RDP or database or WordPress. They're using leaked (or common) credentials - which is still a threat to any other type of service.

(That, or they exploit a history of vulnerabilities in the software behind things like RDP or databases - and you should assume that all of the software you're using has vulnerabilities... which are most severe in highly trusted systems like a control plane...)

OpenSSH is carefully designed with security in mind, far more widely used than Kubernetes, with a fairly minimized attack surface. Nginx is probably a bit less carefully designed, but also doesn't generally have full access to the entire system.

Nginx needs to be open to the Internet at large to work (assuming it's running a public website or something). And you probably need some way to manage it from the Internet. I'd say SSH is a pretty good choice there, especially over Kubernetes.

Re: Why the hell is your Kubernetes API public?

#33

Post by Repulsion9513 »

ufmace wrote: post #17

Thought about it for a few seconds, and yeah, I'm sticking with meh on this one. I do have a managed K8s cluster running on one of the major hosting services. It seems I can indeed hit the /healthz endpoint without auth. But I don't see any reason to care. First off, the control plane URL is a UUID tacked onto the hosting service's DNS. Good luck figuring out what it is starting from the URLs of the sites hosted on i…

The most plausible attacker is, IMO, someone scanning the Internet en masse for 0day or 1day vulns that haven't been patched yet. Which not exposing it to the Internet prevents.

Most (initial) attacks are not targeted at you, they're just scanning the whole Internet.

Re: Why the hell is your Kubernetes API public?

#34

Post by Repulsion9513 »

empath-nirvana wrote: post #12

There is no such thing as a "private" network that is magically more secure than the internet, and if you don't trust it on the internet, you shouldn't trust it on your private network. If you have anything of value, there are going to be bad actors poking around in your private network eventually.

> there are going to be bad actors poking around in your private network eventually

Sure, but will those bad actors be poking around in your network at the same time as you've got an unpatched vulnerability in Kubernetes? Or will it just be the 1000s of Internet scanners and botnets looking to exploit it?

> There is no such thing as a "private" network that is magically more secure than the internet

Obviously there is, although it's not magic. I could equally say "There is no such thing as a 'private' key that is magically more secure than nothing".

> if you don't trust it on the internet, you shouldn't trust it on your private network

This bit is true. But just because you trust it doesn't mean it needs to be exposed.

Re: Why the hell is your Kubernetes API public?

#36

Post by ofrzeta »

I know it's considered security through obscurity but it still makes sense for me to run sshd on a different port. And so it might be a good idea to use a different port than 6443 for the Kubernetes API. It doesn't make anything more secure per se but it helps evading automated scanners and reduces noise in the logs which helps in security monitoring.

Re: Why the hell is your Kubernetes API public?

#37

Post by captn3m0 »

vbezhenar wrote: post #7

It is public, so what? Obviously cloud operators consider it secure enough to offer that option by default. What are the reasons to consider it not secure?

I'll have to look it up, but there was an unauthenticated exploit against the control plane a while ago. Probably https://blog.appsecco.com/analysing-and-exploiting-kubernete... CVE-2018–1002105

Re: Why the hell is your Kubernetes API public?

#38

Post by OJFord »

ofrzeta wrote: post #36

I know it's considered security through obscurity but it still makes sense for me to run sshd on a different port. And so it might be a good idea to use a different port than 6443 for the Kubernetes API. It doesn't make anything more secure per se but it helps evading automated scanners and reduces noise in the logs which helps in security monitoring.

Yeah, sometimes I think that quip/rule is unhelpful. The King of England's or US President's driving routes are known only to the convoy and staff who need to know for example, that massively raises the bar for someone hoping to make some kind of disruption to it, it reduces the number of threats/actors they need to worry about it, surely it's fair to say it increases security and that's why they do it.

I think the line should be 'obscurity can never provide total security' [but it can be a valuable component].

Re: Why the hell is your Kubernetes API public?

#39

Post by weikju »

arrakeenrevived wrote: post #31
weikju wrote: post #24

Earlier quoted context omitted.

While I agree is likely secure enough, remember that cloud operators such as Aws used to be ok with making s3 buckets public by default, which did cause many issues until they finally changed that (and made it harder to make them public even intentionally).

S3 buckets have never been public by default. They were, however, very easy to make public before things like Block Public Access existed, so lazy devs would just click that button rather than doing proper access control.

I stand corrected.
Post reply on HN