Live data from Hacker News

Kubernetes Security – Best Practice Guide

github.com

21–30 of 45 posts

Re: Kubernetes Security – Best Practice Guide

#24
post #4

Best practice: don't roll your own Kubernetes cluster and use a distribution like OpenShift[1]. They take care of providing, among others, a secure default configuration. [1]: https://github.com/openshift/origin

It would be nice to know how OpenShift deviates from vanilla Kubernetes in terms of security and best practices. I used kubeadm to install my K8s PoC cluster and from what I've read it utilizes best practices for a "reasonably secure" installation. https://kubernetes.io/docs/setup/independent/create-cluster-...

Well first of all OpenShift enforces that no pods can run as root. That's a pretty big deviation from vanilla Kubernetes right out of the box.

Re: Kubernetes Security – Best Practice Guide

#25
post #2

It would help a lot to have a Why for each section. For example, why use a private topology? Why block access to the AWS Metadata API? 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.

Indeed very helpful, I created issues on Github.

Re: Kubernetes Security – Best Practice Guide

#27

Not included, but I would like to see how to inject secrets when running an image.

Kubernetes has great built-in support for injecting secrets as either environment variables (like API keys) or volume mounts (for things like certs). You can configure them to be encrypted at rest as well. https://kubernetes.io/docs/concepts/configuration/secret/ https://kubernetes.io/docs/tasks/administer-cluster/encrypt-...

one thing to watch there is that you have to be using a relatively recent version (1.9+ IIRC) to get encrypted at rest for secrets in base Kubernetes

Re: Kubernetes Security – Best Practice Guide

#29
From my experience of reviewing Kubernetes deployments for security here's where I'd start on securing Kubernetes.

- 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.

- 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.

- 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.

- Turn off unauthenticated information APIs like cAdvisor and the read-only kubelet port, if you don't need them.

- Implement PodSecurityPolicy to reduce the risk of containers compromising the hosts

Re: Kubernetes Security – Best Practice Guide

#30
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.)
Post reply on HN