TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Kubernetes Security – Best Practice Guide

212 点作者 aboutsimon大约 7 年前

13 条评论

iooi大约 7 年前
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&#x27;m not saying it&#x27;s wrong to do those things, but it would help to prioritize changes if you can understand the severity of the security vulnerabilities you&#x27;re exposed to.
评论 #16767298 未加载
评论 #16766728 未加载
评论 #16767911 未加载
raesene9大约 7 年前
From my experience of reviewing Kubernetes deployments for security here&#x27;s where I&#x27;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&#x27;t do that consistently and from all perspectives. Whilst the API server generally is configured like this, I&#x27;ve seen setups where either etcd and&#x2F;or the Kubelet are not and that&#x27;s generally going to lead to compromise of the cluster.<p>- Ensure that you&#x27;ve got RBAC turned on and&#x2F;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&#x27;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&#x27;t need them.<p>- Implement PodSecurityPolicy to reduce the risk of containers compromising the hosts
评论 #16768082 未加载
hardwaresofton大约 7 年前
Some excellent talks on defense in depth with Kubernetes:<p>- Hacking and hardening Kubernetes Clusters by Example by Brad Geesaman -&gt; <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=vTgQLzeBfRU" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=vTgQLzeBfRU</a><p>- Shipping in Pirate-Infested Waters: Practical Attack and Defense in Kubernetes by Greg Castle -&gt; <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ohTq0no0ZVU" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ohTq0no0ZVU</a>
swozey大约 7 年前
You recommend RBAC but then state that the k8s-dash starts with full permissions. That&#x27;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&#x27;t set up its RBAC svc account you won&#x27;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&#x2F;very limited permissions.<p>Definitely suggest adding more RBAC examples to this. And things like ETCD w&#x2F;SSL, etc.
评论 #16766584 未加载
评论 #16767611 未加载
mcdan大约 7 年前
Another tool that can help here: <a href="https:&#x2F;&#x2F;github.com&#x2F;aquasecurity&#x2F;kube-bench" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;aquasecurity&#x2F;kube-bench</a>
评论 #16766141 未加载
评论 #16767890 未加载
评论 #16766302 未加载
评论 #16767922 未加载
raesene9大约 7 年前
If you&#x27;re interested in Kubernetes security, I&#x27;d recommend looking at the CIS benchmark <a href="https:&#x2F;&#x2F;www.cisecurity.org&#x2F;benchmark&#x2F;kubernetes&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.cisecurity.org&#x2F;benchmark&#x2F;kubernetes&#x2F;</a> which is relatively well maintained and has a lot of information about possible Kubernetes security configuration.
评论 #16768088 未加载
lima大约 7 年前
Best practice: don&#x27;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:&#x2F;&#x2F;github.com&#x2F;openshift&#x2F;origin" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;openshift&#x2F;origin</a>
评论 #16766662 未加载
评论 #16767044 未加载
erikb大约 7 年前
Basics are missing, e.g. don&#x27;t run privileged containers, don&#x27;t give all your pods cluster-admin rights, don&#x27;t allow random hostpath mounting. (You would be surprised how much software couldn&#x27;t run if this would really be enforced.)
praving5大约 7 年前
Have you seen CIS Kubernetes Benchmark? It has 100+ security check points.
评论 #16767930 未加载
collinf大约 7 年前
Security guide is for RHEL6? Nobody is actually running K8s on RHEL6 without systemd, are they? Are they?!?!
评论 #16770462 未加载
评论 #16770476 未加载
darren0大约 7 年前
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&#x27;re own cluster you really need a guide like this. It&#x27;s very easy to create a very insecure cluster. People are actively targeting poorly configured k8s clusters too. It doesn&#x27;t take to long before you start mining Bitcoin :)
mugsie大约 7 年前
The main kubernetes docs have a good section on this as well.<p><a href="https:&#x2F;&#x2F;kubernetes.io&#x2F;docs&#x2F;tasks&#x2F;administer-cluster&#x2F;securing-a-cluster&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kubernetes.io&#x2F;docs&#x2F;tasks&#x2F;administer-cluster&#x2F;securing...</a>
corpMaverick大约 7 年前
Not included, but I would like to see how to inject secrets when running an image.
评论 #16767193 未加载
评论 #16766371 未加载