2 ms·

Whilst Kubernetes defaults are indeed not great, they aren't that relevant unless you're building your clusters from scratch instead of using a k8s distribution

Whilst Kubernetes defaults are indeed not great, they aren't that relevant unless you're building your clusters from scratch instead of using a k8s distribution, and I don't think I've seen anyone do that in a long time. RBAC is enabled by default on just about every distribution I've seen (with the notable exception of microk8s) Lack of default admission control to prevent someone with pod creation access breakout to the host is indeed pretty common Unencrypted APIs hasn't really been a problem in years, the insecure API port and read-only Kubelet were a thing but they've been disabled for quite a few versions now. I'd definitely agree that early k8s versions had very bad security, but things have been improving gradually over the versions :)

0xbadcafebee 3y ago
Well first of all, there are still thousands of clusters running with the old insecure defaults, so that's bad. Both GKE and EKS currently have insecure defaults. There's a half dozen ways to take over the entire cluster with the default settings. The unencrypted API port is only this year being deprecated on GKE, I don't know about EKS. Since you can only grant permissions, not deny, most people end up granting too many permissions, defeating the purpose of least privilege. Default permissions for users on GKE/EKS are way too wide open. You can do things you just shouldn't need to do as a regular dev. You shouldn't be able to just deploy a helm chart to a random cluster and then all of a sudden there's an unauthenticated public service on the internet. But that's what every single distribution of K8s gives users by default. Regardless of whether you think that's fine or not, this is how companies get exposed on a regular basis, so it is a real-world persistent security problem that is perpetuated by the defaults.
- raesene9 3y ago
  People not upgrading is indeed a problem but not one the distributions or k8s can particularly address, unless they force upgrade people which with deprecation/removal of APIs doesn't tend to be popular :) The support lifecycle is pretty short, compared to general enterprise software, so unless orgs are happy running unsupported versions of k8s they're on 1.23 for EKS or 1.24 for GKE by this point. I wouldn't have said that EKS, in particular, had very bad defaults, IME it's the best of the managed distributions for security. Any references for 1/2 dozen ways of taking over a cluster from defaults settings? I'd genuinely be interested as I collect information about Kubernetes security, so I'm always on the look-out for more references. for unencrypted API are you thinking of the Insecure API port or read-only Kubelet? For the insecure API port I don't think that's been a thing for a really long time on managed distros. The only time I remember seeing it was on ACS (the predecessor to AKS) where it was exposed to the container network. read-only Kubelet was more of a thing as that was on worker nodes, but it was less risky.

0xbadcafebee 3y ago

Well first of all, there are still thousands of clusters running with the old insecure defaults, so that's bad. Both GKE and EKS currently have insecure defaults. There's a half dozen ways to take over the entire cluster with the default settings. The unencrypted API port is only this year being deprecated on GKE, I don't know about EKS. Since you can only grant permissions, not deny, most people end up granting too many permissions, defeating the purpose of least privilege. Default permissions for users on GKE/EKS are way too wide open. You can do things you just shouldn't need to do as a regular dev. You shouldn't be able to just deploy a helm chart to a random cluster and then all of a sudden there's an unauthenticated public service on the internet. But that's what every single distribution of K8s gives users by default. Regardless of whether you think that's fine or not, this is how companies get exposed on a regular basis, so it is a real-world persistent security problem that is perpetuated by the defaults.

raesene9 3y ago
People not upgrading is indeed a problem but not one the distributions or k8s can particularly address, unless they force upgrade people which with deprecation/removal of APIs doesn't tend to be popular :) The support lifecycle is pretty short, compared to general enterprise software, so unless orgs are happy running unsupported versions of k8s they're on 1.23 for EKS or 1.24 for GKE by this point. I wouldn't have said that EKS, in particular, had very bad defaults, IME it's the best of the managed distributions for security. Any references for 1/2 dozen ways of taking over a cluster from defaults settings? I'd genuinely be interested as I collect information about Kubernetes security, so I'm always on the look-out for more references. for unencrypted API are you thinking of the Insecure API port or read-only Kubelet? For the insecure API port I don't think that's been a thing for a really long time on managed distros. The only time I remember seeing it was on ACS (the predecessor to AKS) where it was exposed to the container network. read-only Kubelet was more of a thing as that was on worker nodes, but it was less risky.