注意事项 佩雷夫 ：这不是我们在博客上翻译的关于Kubernetes的具有一般安全建议的第一篇文章 。 但是，它的相关性（至少是提醒一些简单而重要的事情，由于时间紧迫而不应被视而不见）仅由作者在材料开始时提到的最近事件来证实。 顺便说一下，作者是StackRox的产品经理Connor Gilbert，这是一个现成的平台，用于保护Kubernetes集群中部署的应用程序。 因此，这是他为CNCF博客读者提供的建议...
注意 ：为了使本文更具参考性，对于作者提到的某些术语/方法，我们添加了相关文档的链接。
上个月，世界上最流行的容器编排系统Kubernetes
发现了第一个严重的安全漏洞，该漏洞袭击了该项目的生态系统。 漏洞
CVE-2018-1002105允许攻击者通过Kubernetes API服务器破坏群集，该服务器允许执行恶意代码以安装恶意软件等。
在今年早些时候，Kubernetes控制面板的错误配置导致特斯拉资源
安装了加密货币挖掘软件。 然后，攻击者利用了Kubernetes面板之一不受密码保护的事实，这使他们可以使用一个帐户访问其中一个Pod来访问AWS中更大的Tesla基础架构。
加快容器及其编排的实施速度的组织还需要采取强制性步骤来保护其基础架构的这一关键部分。 以下是基于客户数据的Kubernetes最佳安全实践中的九种：遵循它们，以更好地保护您的基础架构。
1.更新到最新版本
在[Kubernetes]的每个季度发行版中，不仅提供了错误修复，而且还提供了新的安全功能：要利用它们，我们建议使用最新的稳定版本。
鉴于最近发现的CVE-2018-1002105，使用具有最新补丁程序的最新版本将特别重要。 更新和支持可能比发行版中提供的新功能困难，因此，至少每季度计划一次更新。
可以使用托管的Kubernetes解决方案的提供程序来显着简化更新。
2.启用基于角色的访问控制（RBAC）
使用
RBAC （基于角色的访问控制）来控制谁可以访问Kubernetes API以及他们具有哪些权限。 通常，默认情况下，在Kubernetes 1.6版或更高版本中（或对于某些提供程序而言是更高版本）默认情况下启用RBAC，但是如果此后已更新且未更改配置，则应仔细检查设置。 由于组合了Kubernetes中授权控制器的工作的机制
（有关一般操作顺序，请参见文章“ kubectl运行开始时Kubernetes中会发生什么？第1部分 ”）- 大约。 （基于属性的访问控制）。
但是，启用RBAC是不够的-仍然需要有效地使用它。 在一般情况下，应避免对整个群集
（群集范围内）的权限，而应优先考虑某些命名空间中的权限。 即使在调试时也要避免给集群管理员特权-仅在必要时不时授予权限更为安全。
您可以看到集群角色，而只是通过
kubectl get clusterrolebinding或
kubectl get rolebinding --all-namespaces查看角色。 因此，您可以快速检查将
cluster-admin角色
cluster-admin谁（在此示例中，仅适用于
masters组）：
$ kubectl describe clusterrolebinding cluster-admin Name: cluster-admin Labels: kubernetes.io/boostrapping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate=true Role: Kind: ClusterRole Name: cluster-admin Subjects: Kind Name ---- ---- Group system:masters Namespace ---------
如果应用程序需要访问Kubernetes API，请创建单独的服务帐户
（在本材料中了解有关它们的更多信息- 大约Transl。 ），并为他们提供每种用例所需的最少权限。 这种方法比给名称空间中的默认帐户过多的特权要好得多。
大多数应用程序根本不需要访问API：
可以将它们的
automountServiceAccountToken 设置为
false 。
3.使用名称空间设置安全边界
创建单独的名称空间对于组件隔离的第一级很重要。 当不同类型的工作负载部署在单独的命名空间中时，调整安全设置（例如，网络策略）要容易得多。
您的团队是否有效使用命名空间？ 检查其列表是否为非标准（默认情况下未创建）：
$ kubectl get ns NAME STATUS AGE default Active 16m kube-public Active 16m kube-system Active 16m
4.分离敏感的工作负载。
限制危害潜在后果的一个好习惯是在一组专用的计算机上运行带有敏感数据的工作负载。 这种方法降低了安全性较低的应用程序使用敏感数据访问该应用程序的风险，这些敏感数据运行在同一容器可执行环境或同一主机上。 例如，受感染节点的kubelet通常仅在将秘密内容安装在计划在同一节点上执行的Pod上时，才可以访问秘密内容。 如果可以在多个群集节点上找到重要机密，则攻击者将有更多机会来获取这些机密。
可以使用
节点池 -
节点池 （在云中或本地）或Kubernetes控制机制（例如名称空间，
污点，容忍度等）来完成分离。
5.保护对云服务元数据的访问
敏感的元数据（例如，kubelet管理凭据）可能会被盗用或出于恶意目的升级群集中的特权。 例如，
最近 Shopify的漏洞赏金发现详细显示了用户如何通过使用专门为一种微服务生成的数据从云提供商接收元数据来超越权限。
在GKE中，
元数据隐藏功能，
元数据隐藏以一种避免此类问题的方式更改了部署群集的机制，我们建议在实现永久解决方案之前使用它。
在其他环境中可能需要采取类似的对策。
6.创建和定义群集网络策略
网络策略-
网络策略 -允许您控制与容器化应用程序之间的网络访问。 要使用它们，您必须具有支持此类资源的网络提供商。 对于托管的Kubernetes解决方案提供商，例如Google Kubernetes Engine（GKE），将需要启用支持。 （为GKE中的现有群集启用网络策略将需要进行简短的滚动更新。）
一旦一切准备就绪，就从简单的默认网络策略开始-例如，（默认情况下）阻止来自其他名称空间的流量。
如果您使用的是Google Container Engine，则可以检查是否在工作群集上启用了策略支持：
$ gcloud container clusters list \ --format='table[box] (name,addonsConfig.networkPolicyConfig)'
7.设置集群的Pod安全策略。
Pod安全策略-Pod安全策略 -设置用于启动集群中工作负载的默认值。 考虑定义策略并启用Pod Security Policy
准入控制器 ：这些步骤的说明会根据所使用的云提供商或部署模型而有所不同。
对于初学者，您可能
NET_RAW容器中
NET_RAW 功能 ，以保护自己免受某些类型的欺骗攻击。
8.开展节点安全性工作
要提高主机安全性，您可以按照以下步骤操作：
- 确保安全且正确地配置了主机 。 一种方法是CIS基准测试 ； 许多产品都有自动检查器，可以自动检查系统是否符合这些标准。
- 监视重要端口的网络可用性 。 确保网络阻止访问kubelet使用的端口，包括10250和10255。考虑限制对Kubernetes API服务器的访问-受信任的网络除外。 在不需要kubelet API进行身份验证和授权的群集中，攻击者使用对此类端口的访问来启动加密货币矿工。
- 最小化对Kubernetes主机的管理访问 。 原则上应该限制对群集节点的访问：通常，对于调试和解决其他问题，您可以不直接访问节点而进行操作。
9.启用审核日志记录
确保启用了
审核日志 ，并且正在监视其中的异常或不需要的API调用的发生，尤其是在任何授权失败的情况下-此类条目将显示一条消息，显示为“禁止”状态。 授权失败可能意味着攻击者试图利用获得的凭据。
托管解决方案提供商（包括GKE）可以在其界面中访问此数据，并可以帮助您在授权失败的情况下设置通知。
展望未来
请遵循以下准则以获得更安全的Kubernetes集群。 请记住，即使在安全地配置了集群之后，也必须确保容器配置和操作的其他方面的安全性。 为了提高技术堆栈的安全性，请探索提供用于管理已部署容器，不断监视和保护容器和云本机应用程序的中央系统的工具。
译者的PS
另请参阅我们的博客：