如何利用开放措施代理保护Kubernetes

随着越来越多的组织将容器化应用程序转移到生产环境中，Kubernetes已经成为在私有云、公共云和混合云环境中管理这些应用程序的有效方法。事实上，根据云原生计算基金会的调查，至少84%的组织已经在业务中使用容器，78%的组织利用Kubernetes来部署容器。

 

Kubernetes的强大功能和吸引力在于，与大多数现代API不同，Kubernetes API是基于意图的，这意味着使用它的组织只需要考虑让Kubernetes做什么，而不是他们希望采用Kubernetes如何实现这个目标。这是一个具有可扩展性、弹性且因此流行的系统。总而言之，Kubernetes加快了应用交付速度。

然而，云原生环境中的变化在设计上是不变的，这意味着其运行是非常动态的。动态性和大规模成为一个公认的风险解决方案，而当今的现代环境确实带来了新的安全性、操作性和合规性的挑战。考虑以下问题：当工作负载仅存在几微秒时，如何控制它的特权级别?当所有服务都是动态构建且只根据需要构建时，如何控制哪些服务可以访问全球互联网?混合云环境中的外围在哪里?由于云原生应用程序是短暂且动态的，因此确保其安全的要求要复杂得多。

Kubernetes在授权方面的挑战

而且，Kubernetes在授权方面面临了独特的挑战。在过去，“授权”这个简单的术语提出了人们可以执行哪些操作或“谁可以执行什么操作”的概念。但是在容器化的应用程序中，该概念已经得到更大扩展，也包括了哪个软件或哪些机器可以执行哪些操作(也称为“什么可以做什么”)的概念。一些分析师开始使用“业务授权” 这个术语指代以帐户为中心的规则，而“基础设施授权”则用于其他所有内容。当给定的应用程序有一个由15名开发人员组成的团队，但由具有数千个服务的数十个集群组成，并且它们之间有无数的连接时，很明显，“能做什么”规则比以往任何时候都更加重要，并且开发人员需要用于在Kubernetes中创建、管理和扩展这些规则的工具。

因为Kubernetes API是基于YAML的，所以授权决策需要分析YAML的任意块以做出决策。这些YAML块应为每个工作负载定义配置。例如执行一项策略，确保所有图像都来自受信任的存储库，需要扫描YAML以找到所有容器的列表，在该列表上进行迭代，提取特定的图像名称，然后对该图像名称进行字符串解析。例如，另一个策略可能是“防止服务以root身份运行”，这将需要扫描YAML以找到容器列表，在这个列表上进行迭代以检查是否有特定于容器的安全设置，然后组合这些设置具有全局安全性参数。不幸的是，没有任何传统的“业务授权”访问控制解决方案(例如基于角色或基于属性的访问控制、IAM策略等)具有足够强大的功能来强制执行上述基本策略，甚至只需简单更改Pod上的标签。

即使在快速发展的容器世界中，只有一件事仍然保持不变：安全性的优先级经常排在后面。如今，很多组织的DevSecOps团队致力于将安全性转移到开发周期中，但是如果没有合适的工具，往往会在更晚的时候发现并补救挑战和合规性问题。实际上，为了真正满足DevOps流程的上市时间目标，必须在开发流程中更早地实施安全和合规性策略。事实证明，在开发的早期阶段消除风险之后，安全策略才能发挥最大作用，这意味着在交付流程结束时不太可能出现安全问题。

但是，并非所有开发人员都是安全专家，并且对于不堪重负的DevOps团队来说，确保对所有YAML配置进行人工检查是保证成功的途径。但是组织不必为了提高效率而牺牲安全性。开发人员需要适当的安全工具，通过实施护栏来消除失误和风险，从而加快开发速度，从而确保Kubernetes部署符合法规要求。组织需要采用一种改进总体流程的方法，该方法对开发人员、运营、安全团队和业务本身都是有益的。好消息是，有一些可与现代管道自动化和“作为代码”模型一起使用的解决方案可以减少错误和工作量。

输入开放政策代理

开放策略代理(OPA)越来越多地成为Kubernetes首选的“谁可以做什么”和“什么可以做什么”工具。开放策略代理(OPA)是由Styra公司创建的开源策略引擎，它为业务和基础设施授权提供了与域无关的独立规则引擎。开发人员发现开放策略代理(OPA)非常适合Kubernetes，因为它的设计前提是有时组织需要基于任意JSON/YAML编写和实施访问控制策略(以及许多其他策略)。开放策略代理(OPA)作为一种政策规范工具，可以提高Kubernetes开发的速度和自动化程度，同时提高安全性并降低风险。

实际上，Kubernetes是开放策略代理(OPA)最受欢迎的用例之一。如果组织不想为Kubernetes编写、支持和维护自定义代码，则可以将开放策略代理(OPA)用作Kubernetes接纳控制器，并充分利用其声明性策略语言Rego。例如，组织可以采用所有Kubernetes访问控制策略(通常存储在Wiki和PDF中以及人们的头脑中)，并将它们转换为策略即代码。这些策略可以直接在集群上执行，并且在Kubernetes上运行应用程序的开发人员在工作时无需经常引用内部Wiki和PDF策略。这样可以减少错误，并在开发过程的早期消除不利部署，所有这些都可以提高生产率。