随着基于容器的技术的迅速采用，组织越来越关注Kubernetes集群的安全性。虽然云和企业发行版提供了可靠的安全功能，但它们需要根据组织的安全要求进行调整。本文将描述保护Kubernetes集群需要考虑的三个基本领域：基于角色的访问控制(RBA)开放策略代理(OPA)网络策略基于角色的访问控制考虑一个拥有三个应用程序团队（蓝队、绿队、和红队）。由于这些团队开发的产品不同，因此应该授予他们不同的访问Kubernetes集群的权限。例如，绿队和红队不应查看、访问或删除蓝队部署的集群。RBAC是一种控制用户可以访问哪些Kubernetes资源的方法。尽管默认情况下启用RBAC，但必须对其进行配置才能使用它。RBAC有五个关键元素：Subject-用户和进程资源-应该限制访问的对象Actions-可以执行的操作（通常称为动作）Collection角色-将API资源连接到动作的对象角色绑定——连接的对象主题的角色也可以回到以前的组织并定义只有蓝队才能创建、删除和列出Pod、Deployments和Services的策略。我们首先创建一个名为“role-blue”的角色对象，我们在其中定义可以对特定Kubernetes资源执行的操作。在这种特定情况下，角色允许对资源进行“创建”、“删除”和“列出”等操作：Pod、Deployments和Services。接下来，我们创建一个名为“blue-rb”的角色装备。这个角色绑定属于“blue-ns”，它将上面创建的角色“role-blue”与名为“blue”的蓝色团队相关联。一旦将这些资源提交给集群，“蓝色”团队的用户就可以执行“角色-蓝色”中定义的操作。OpenPolicyAgentOpenPolicyAgent(OPA)是一种通用策略引擎，可统一整个堆栈中的策略实施。其高级声明性语言提供了将策略指定为代码的灵活性。您可以使用OPA在Kubernetes、CI/CD管道或API网关中实施策略。深入了解它是如何在Kubernetes中使用和实现的。Kubernetes实现OPA的机制称为Gatekeeper。它被设计和部署为准入控制器，负责拦截请求、处理它们并返回允许或拒绝响应。如果允许，则将对象部署到集群；否则，请求将被拒绝并向用户提供反馈。管理员可以定义策略来指示Kubernetes限制容器或命名空间可以消耗的资源（例如内存或CPU），仅批准基于来自特定注册表的图像的容器，限制NodePort服务创建或强制执行标准命名。例如，下面是一个示例模板和约束策略，仅当在命名空间中配置了ResourceQuota时才允许创建Pod。网络策略网络策略与常规防火墙非常相似，只是它们以应用程序为中心。为应用程序定义网络策略后，Kubernetes会自动将这些规则应用于关联的容器，因为容器会在高度动态的环境中不断创建和终止。网络策略控制进出这些容器的流量。默认情况下，进出pod的网络流量不受限制。一个好的起点是设置拒绝所有流量的规则，然后只允许必要的流量。默认情况下，Kubernetes使用扁平网络结构，允许任何pod与集群中的其他pod或服务进行通信。在具有多个应用程序或多层应用程序的集群中，深度防御在保护通信层方面起着关键作用。网络政策使我们能够做到这一点。这是一个“app1-network-policy”，它在标签为“role=db”的pod的“blue”命名空间中应用以下规则：[Ingress]allowconnectionsfromipBlock172.17.0.0/24onport6379。[Ingress]如果其他Pod被标记为“role=frontend”并且它们属于端口6379上带有标签“project=myproject”的命名空间，则允许来自其他Pod的连接。[Egress]Pod可以与IP范围10.0中的其他Pod通信.0.0/24viaport5978.原标题：保护Kubernetes集群的3个关键要素，作者：AvinashDesireddy
