It would help a lot to have a <i>Why</i> for each section. For example, why use a private topology? Why block access to the AWS Metadata API?<p>I'm not saying it's wrong to do those things, but it would help to prioritize changes if you can understand the severity of the security vulnerabilities you're exposed to.
From my experience of reviewing Kubernetes deployments for security here's where I'd <i>start</i> on securing Kubernetes.<p>- Make sure that all the management interfaces require authentication, including the Kubelet, etcd and API Server. some distributions don't do that consistently and from all perspectives. Whilst the API server generally is configured like this, I've seen setups where either etcd and/or the Kubelet are not and that's generally going to lead to compromise of the cluster.<p>- Ensure that you've got RBAC turned on and/or stop service tokens being mounted into pods. Having a cluster-admin level token being mounted into pods by default is quite dangerous if an attacker can compromise any app. component running on your cluster.<p>- Block access to metadata if your running in the cloud. For example, if you're running your k8s cluster on EC2 VMs any attacker who compromises one container, can use the metadata service to get the IAM token for the EC2 machine, which can be bad for your security :) this is likely to be done with Network Policy, so you can use that to do things like block access from the container network to the Node IP addresses as well.<p>- Turn off unauthenticated information APIs like cAdvisor and the read-only kubelet port, if you don't need them.<p>- Implement PodSecurityPolicy to reduce the risk of containers compromising the hosts
Some excellent talks on defense in depth with Kubernetes:<p>- Hacking and hardening Kubernetes Clusters by Example by Brad Geesaman -> <a href="https://www.youtube.com/watch?v=vTgQLzeBfRU" rel="nofollow">https://www.youtube.com/watch?v=vTgQLzeBfRU</a><p>- Shipping in Pirate-Infested Waters: Practical Attack and Defense in Kubernetes by Greg Castle -> <a href="https://www.youtube.com/watch?v=ohTq0no0ZVU" rel="nofollow">https://www.youtube.com/watch?v=ohTq0no0ZVU</a>
You recommend RBAC but then state that the k8s-dash starts with full permissions. That's not true at all when using RBAC. You need to define which namespaces, resources, etc get accessed. Right now with k8s if you deploy RBAC + k8s-dash (which is basically deprecated anyway) and don't set up its RBAC svc account you won't be able to view things in k8s without putting in your personal admin token because it would use the default service account which has no/very limited permissions.<p>Definitely suggest adding more RBAC examples to this. And things like ETCD w/SSL, etc.
Another tool that can help here: <a href="https://github.com/aquasecurity/kube-bench" rel="nofollow">https://github.com/aquasecurity/kube-bench</a>
If you're interested in Kubernetes security, I'd recommend looking at the CIS benchmark <a href="https://www.cisecurity.org/benchmark/kubernetes/" rel="nofollow">https://www.cisecurity.org/benchmark/kubernetes/</a> which is relatively well maintained and has a lot of information about possible Kubernetes security configuration.
Best practice: don't roll your own Kubernetes cluster and use a distribution like OpenShift[1].<p>They take care of providing, among others, a secure default configuration.<p>[1]: <a href="https://github.com/openshift/origin" rel="nofollow">https://github.com/openshift/origin</a>
Basics are missing, e.g. don't run privileged containers, don't give all your pods cluster-admin rights, don't allow random hostpath mounting. (You would be surprised how much software couldn't run if this would really be enforced.)
Shameless plug: Try Rancher 2.0 (beta announced today and GA coming in a month). With Rancher we enable all the security stuff by default but try to actually make it usable (which is quite hard). So RBAC, PSPs, network policy is all on by default. We give you quite a bit of tools to manage RBAC and PSP.<p>If you are managing you're own cluster you really need a guide like this. It's very easy to create a very insecure cluster. People are actively targeting poorly configured k8s clusters too. It doesn't take to long before you start mining Bitcoin :)
The main kubernetes docs have a good section on this as well.<p><a href="https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/" rel="nofollow">https://kubernetes.io/docs/tasks/administer-cluster/securing...</a>