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

Kubernetes Security – Best Practice Guide

github.com

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Kubernetes Security – Best Practice Guide

#11

Post by towolf »

swozey wrote: post #7

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…

Someone installed the dashboard for us before the RBAC stuff was added. The fun started when we realized that the old ClusterRoleBinding needed to be deleted manually.

Clicking SKIP hence gave full access until we did.

It's nice when things are idempotent, but removing stray things that should go absent is usually overlooked.

Re: Kubernetes Security – Best Practice Guide

#12

Post by hardwaresofton »

Some excellent talks on defense in depth with Kubernetes:

- Hacking and hardening Kubernetes Clusters by Example by Brad Geesaman -> https://www.youtube.com/watch?v=vTgQLzeBfRU

- Shipping in Pirate-Infested Waters: Practical Attack and Defense in Kubernetes by Greg Castle -> https://www.youtube.com/watch?v=ohTq0no0ZVU

Re: Kubernetes Security – Best Practice Guide

#13

Post by stuff4ben »

lima wrote: 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-...

Re: Kubernetes Security – Best Practice Guide

#14

Post by tokenizerrr »

iooi wrote: 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.

Yes please! It's one thing to know what you should do because you've been told to do so, but quite another to fully understand why you're doing something.

Re: Kubernetes Security – Best Practice Guide

#15

Post by snupples »

lima wrote: 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

How precisely does it provide a secure default configuration. As far as I can tell it enables very few security features built-in to kubernetes (of which there are many not enabled by default or require configuration to properly enable). It's still up to the administrator to secure.

Edit: Not to mention your comment doesn't address half the article, which dives into security tangential to kubernetes itself such as AWS

Re: Kubernetes Security – Best Practice Guide

#16

Post by snupples »

stuff4ben wrote: post #13
lima wrote: 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-...

Kubeadm does set up a few security features as long as its a fairly recent version. There are others you still need to configure and/or enable if you need them. (eg NetworkPolicies, OIDC, Encrypted data at rest, etc, etc.) I don't see openshift setting many of these either.

Re: Kubernetes Security – Best Practice Guide

#17

Post by jeffstephens »

corpMaverick wrote: post #6

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

Re: Kubernetes Security – Best Practice Guide

#18

Post by eikenberry »

iooi wrote: 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.

This guide really has no audience. If you are responsible for a K8ts cluster you will need a depth of knowledge that requires knowing why. If you are using a hosted K8ts then you only need to know potential issues (why again). No one needs to know only what to do.

Re: Kubernetes Security – Best Practice Guide

#19

Post by ownagefool »

Diederich wrote: post #10
corpMaverick wrote: post #6

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

At image startup you mean? Or while the image is actively running.

If you use the file based secrets(or configmap), they'll be updated when the underlying secrets are.

Obviously your code would have to handle using these new secrets and not just simply read the file at startup.

Re: Kubernetes Security – Best Practice Guide

#20

Post by Filligree »

swozey wrote: post #7

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…

If k8s-dash is deprecated, what's the replacement?
Post reply on HN