开放策略代理可以通过提供一个完整的工具包来解决Kubernetes授权难题，该工具包用于将声明性策略集成到任意数量的应用程序和基础设施组件中。Kubernetes的强大功能和吸引力在于，与大多数现代API不同，Kubernetes API是基于意图的，这意味着使用它的组织只需要考虑让Kubernetes做什么，而不是他们希望采用Kubernetes如何实现这个目标。
开放策略代理可以通过提供一个完整的工具包来解决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策略。这样可以减少错误，并在开发过程的早期消除不利部署，所有这些都可以提高生产率。
开放策略代理(OPA)可以帮助解决Kubernetes独特挑战的另一种方法是使用场景感知策略。这些策略决定了Kubernetes会根据有关存在的所有其他Kubernetes资源的信息来决定资源的决策。例如，组织可能要避免意外创建一个使用同一入口窃取另一个应用程序的全球互联网流量的应用程序。在这种情况下，组织可以创建一个策略“禁止主机名冲突的入口”，以要求将任何新入口与现有入口进行比较。更重要的是，开放策略代理(OPA)确保Kubernetes的配置和部署符合内部策略和外部监管要求，这对开发人员、运营和安全团队来说都是双赢的措施。
跨混合云保护Kubernetes
通常情况下，当人们说到“ Kubernetes”时，他们实际上是指在Kubernetes容器管理系统上运行的应用程序。这也是使用开放策略代理(OPA)的一种流行方式：让开放策略代理(OPA)决定是否在应用程序内部授权微服务或最终用户操作。因为涉及Kubernetes环境，开放策略代理(OPA)提供了一个完整的工具包，用于测试、试运行、调整以及将声明性策略集成到任意数量的应用程序和基础设施组件中。
实际上，开发人员经常扩大对开放策略代理(OPA)的使用，以在其所有Kubernetes集群中实施策略并提高安全性，尤其是在混合云环境中。为此，许多用户还利用了Styra DAS，这有助于在运行前验证开放策略代理(OPA)安全策略，以查看其影响，将其分发到任意数量的Kubernetes集群中，然后连续监视策略以确保它们具有预期的效果。
无论组织在云计算和容器旅程中的哪个地方， Kubernetes现在都是在生产中部署容器的标准。Kubernetes环境带来了组织必须解决的新的独特挑战，以确保其云计算环境中的安全性和合规性，但是确实存在解决方案限制对基础思维的需求。为了大规模地解决这些挑战，开放策略代理(OPA)已经成为事实上的标准，可以通过自动策略执行来帮助组织降低风险并加快应用交付。
版权声明：本文为企业网D1Net编译，转载需在文章开头注明出处为：企业网D1Net，如果不注明出处，企业网D1Net将保留追究其法律责任的权利。
（来源：企业网D1Net）
