在云原生时代，我们经常听到“没有安全，就没有一切”，这意味着安全比任何事情都重要。

现代基础设施和解决方案让我们受益匪浅，但与此同时，由于有更多的应用服务，所以会有更多的事情需要担心：比如如何控制对基础设施的访问？如何控制服务之间的访问？每个人的访问权限等。

在众多需要回答的问题中，还包括策略方面的：比如一大堆的安全规则、标准和条件。比如：

谁可以访问此资源？

允许来自哪个子网出口流量？

工作负载必须部署到哪些集群？

哪些协议不允许用于从互联网访问的服务器？

可以从哪些注册表二进制文件下载？

容器可以使用哪些操作系统执行功能？

一天中的哪些时间可以访问系统？

所有组织都有策略，因为它们明确了有关遵守法律要求、在技术约束下工作、避免重复错误等重要知识。

为什么选择策略即代码？

策略是基于渗透到组织文化中的成文或不成文的规则。因此，假如我们的组织有一条书面规则明确要求：

对于从Internet上公共子网访问的服务器，使用不安全的“HTTP”协议公开端口不是一个好的做法。

那么我们应该如何执行它？

如果我们手动创建基础设施，“四眼原则”可能会有所帮助。但前提是在做关键事情时，总是有第二个人在一起。

如果我们使用基础设施即代码，并使用 Terraform 等工具自动创建基础设施，那么代码审查可能会有所帮助。

但是，传统的策略实施过程有几个明显的缺点：

不能保证此政策永远不会被打破。人们无法始终了解所有策略，并且根据策略列表进行手动检查是不切实际的。对于代码审查，即使是高级工程师也不太可能每次都发现所有潜在问题。

现代组织是敏捷的，这意味着员工、服务和团队都在持续增长，无法让安全团队使用传统技术来保护所有资产。

由于人为错误，政策迟早会被违反。这不是“如果”的问题，而是“何时”的问题。这也正是大多数组织在主要版本发布之前进行定期安全检查和合规性审查的原因--我们首先违反政策，然后创建事后修复。

这样做不太科学。那么，管理和实施策略的正确方法是什么？

什么是策略即代码 （PaC）？

随着业务、团队成熟度的发展，我们希望从手动定义策略，转变为从企业层面上更易于管理和可重复的定义策略。

如何做到这一点？首先，我们可以从大规模管理系统的成功实验中学习：

基础结构即代码 （IaC）：将定义环境和基础结构的内容视为源代码。

DevOps：人员、流程和自动化的结合，实现“持续的一切”，持续为最终用户提供价值。

策略即代码（PaC）诞生于这些想法。

策略即代码使用代码来定义和管理策略，这些策略是规则和条件。使用代码和利用源代码管理 （SCM） 工具定义、更新、共享和实施策略。通过将策略定义保留在源代码控制中，无论何时进行更改，都可以对其进行测试、验证，然后执行。PaC 的目标不是检测违反策略的行为，而是防止它们犯错误。这利用了 DevOps 自动化功能，而不是依赖手动流程，使团队能够更快地行动，并减少由于人为错误而导致错误的可能性。

策略即代码与基础结构即代码

“即代码”运动并不是新鲜事务，它的目标是“连续的一切”。PaC 的概念可能听起来类似于基础结构即代码 （IaC），但 IaC 侧重于基础结构和预配，而 PaC 改进了安全操作、合规性管理、数据管理等。

PaC 可以与 IaC 集成，以自动实施基础结构策略。

现在我们已经解决了 PaC 与 IaC 的问题，让我们看一下实现 PaC 的工具。

开放策略代理 （OPA） 简介

开放策略代理（OPA，发音为“oh-pa”）是云原生计算基金会孵化项目。它是一个开源的通用策略引擎，旨在为将策略即代码应用于任何领域提供通用框架。

OPA 提供了一种高级声明性语言（Rego，发音为“ray-go”，专为策略构建），允许您将策略指定为代码。因此，您可以在微服务、Kubernetes、CI/CD、API 网关等中定义、实施和实施策略。

简而言之，OPA的工作方式是将决策与政策执行脱钩。当需要做出策略决策时，使用结构化数据（例如 JSON）作为输入来查询 OPA，然后 OPA 返回决策：

先决条件

要开始使用，请从 GitHub 版本下载适用于您的平台的 OPA 二进制文件：

在 macOS（64 位）上：

在 M1 Mac 上测试，也可以工作。

规范

让我们从一个简单的示例开始，为虚构的工资单微服务实现基于访问的访问控制 （ABAC）。

规则很简单：您只能访问您的工资信息或下属的工资信息，而不能访问其他任何人的工资信息。因此，如果是您自己的，或者是您下属的，那么以访问以下内容：bob john

• /getSalary/bob
• /getSalary/john

但是不能以用户身份访问：/getSalary/alicebob

输入数据和Rego文件

假设我们有结构化输入数据（文件）：input.json

让我们创建一个Rego文件。在这里，注释会让你很好地理解这段代码的作用：

文件：example.rego

运行

以下值应计算为：true

改变输入中的路径.json文件到"path": ["getSalary"， "john"]，它的值仍然为“true”，因为第二条规则允许经理查看下属的工资。

但是，如果我们改变输入的路径.json文件到"path": ["getSalary"， "alice"]，结果就是false。

策略即代码集成

上面的例子非常简单，只对掌握 OPA 工作原理的基础知识有用。但是 OPA 功能很强大，可以与当今许多主流工具和平台集成，例如：

Kubernetes

Envoy

AWS CloudFormation

Docker

Terraform

Kafka

为了快速演示 OPA 的功能，下面是在 AWS 上定义自动扩展组和服务器的 Terraform 代码示例：

使用此 Rego 代码，我们可以根据 Terraform 计划计算分数，并根据策略返回决策。自动化该过程非常容易：

terraform plan -out tfplan以创建Terraform规划

terraform show -json tfplan | jq > tfplan.json将计划转换为 JSON 格式

opa exec --decision terraform/analysis/authz --bundle policy/ tfplan.json以获得结果。