您的平台能否执行策略？利用平台 L7 策略功能加速团队
策略是您的核心竞争力吗？可能不是，但您需要正确执行。使用 Istio 和 OPA 一次性完成，让团队专注于最重要的事情。
共享计算平台为租户团队提供资源和共享功能，以便他们无需从头开始构建所有内容。虽然有时很难平衡来自租户的所有请求，但平台团队必须提出一个问题：我们能为租户提供的最有价值的功能是什么？
通常，工作会直接分配给应用程序团队来实施，但有些功能最好实施一次，并作为服务提供给所有团队。大多数平台团队都能实现的功能之一是提供用于第 7 层应用程序授权策略的标准响应系统。策略即代码使团队能够将授权决策从应用程序层提升到一个轻量级且高性能的解耦系统中。这听起来可能像是一个挑战，但使用正确的工具，它并不需要那么复杂。
我们将深入探讨如何使用 Istio 和 Open Policy Agent (OPA) 在您的平台中执行第 7 层策略。我们将向您展示如何使用一个简单的示例入门。您将了解到，这种组合是快速透明地向企业中所有应用程序团队交付策略的可靠选择，同时还为安全团队提供审计和合规所需的数据。
试一试
与 Istio 集成后，OPA 可用于对微服务实施细粒度的访问控制策略。本指南展示了如何对简单的微服务应用程序实施访问控制策略。
先决条件
- 已安装 Istio 的 Kubernetes 集群。
- 已安装
istioctl命令行工具。
安装 Istio 并配置您的 网格选项 以启用 OPA
$ istioctl install -y -f - <<'EOF'
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
accessLogFile: /dev/stdout
accessLogFormat: |
[OPA DEMO] my-new-dynamic-metadata: "%DYNAMIC_METADATA(envoy.filters.http.ext_authz)%"
extensionProviders:
- name: "opa.local"
envoyExtAuthzGrpc:
service: "opa.opa.svc.cluster.local"
port: "9191"
EOF
请注意，在配置中，我们定义了一个 extensionProviders 部分，该部分指向 OPA 独立安装。
部署示例应用程序。Httpbin 是一个众所周知的应用程序，可用于测试 HTTP 请求，并帮助快速演示如何使用请求和响应属性。
$ kubectl create ns my-app
$ kubectl label namespace my-app istio-injection=enabled
$ kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.24/samples/httpbin/httpbin.yaml -n my-app
部署 OPA。它将失败，因为它期望一个包含要使用的默认 Rego 规则的 configMap。此 configMap 将在我们的示例中稍后部署。
$ kubectl create ns opa
$ kubectl label namespace opa istio-injection=enabled
$ kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: opa
name: opa
namespace: opa
spec:
replicas: 1
selector:
matchLabels:
app: opa
template:
metadata:
labels:
app: opa
spec:
containers:
- image: openpolicyagent/opa:0.61.0-envoy
name: opa
args:
- "run"
- "--server"
- "--disable-telemetry"
- "--config-file=/config/config.yaml"
- "--log-level=debug" # Uncomment this line to enable debug logs
- "--diagnostic-addr=0.0.0.0:8282"
- "/policy/policy.rego" # Default policy
volumeMounts:
- mountPath: "/config"
name: opa-config
- mountPath: "/policy"
name: opa-policy
volumes:
- name: opa-config
configMap:
name: opa-config
- name: opa-policy
configMap:
name: opa-policy
---
apiVersion: v1
kind: ConfigMap
metadata:
name: opa-config
namespace: opa
data:
config.yaml: |
# Here the OPA configuration you can find in the offcial documention
decision_logs:
console: true
plugins:
envoy_ext_authz_grpc:
addr: ":9191"
path: mypackage/mysubpackage/myrule # Default path for grpc plugin
# Here you can add your own configuration with services and bundles
---
apiVersion: v1
kind: Service
metadata:
name: opa
namespace: opa
labels:
app: opa
spec:
ports:
- port: 9191
protocol: TCP
name: grpc
selector:
app: opa
---
EOF
部署 AuthorizationPolicy 以定义哪些服务将受 OPA 保护。
$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: my-opa-authz
namespace: istio-system # This enforce the policy on all the mesh being istio-system the mesh config namespace
spec:
selector:
matchLabels:
ext-authz: enabled
action: CUSTOM
provider:
name: "opa.local"
rules: [{}] # Empty rules, it will apply to selectors with ext-authz: enabled label
EOF
让我们为应用程序添加标签以执行策略
$ kubectl patch deploy httpbin -n my-app --type=merge -p='{
"spec": {
"template": {
"metadata": {
"labels": {
"ext-authz": "enabled"
}
}
}
}
}'
请注意，在此资源中，我们定义了您在 Istio 配置中设置的 OPA extensionProvider
[...]
provider:
name: "opa.local"
[...]
工作原理
应用 AuthorizationPolicy 后，Istio 控制平面 (istiod) 会将所需的配置发送到策略中所选服务的 sidecar 代理 (Envoy)。然后，Envoy 将请求发送到 OPA 服务器以检查请求是否允许。
Envoy 代理通过在一个链中配置过滤器来工作。其中一个过滤器是 ext_authz，它使用特定消息实现外部授权服务。任何实现正确 protobuf 的服务器都可以连接到 Envoy 代理并提供授权决策；OPA 就是这些服务器之一。
之前，在安装 OPA 服务器时，您使用了 Envoy 版本的服务器。此镜像允许配置 gRPC 插件，该插件实现 ext_authz protobuf 服务。
[...]
containers:
- image: openpolicyagent/opa:0.61.0-envoy # This is the OPA image version which brings the Envoy plugin
name: opa
[...]
在配置中，您已启用 Envoy 插件以及将侦听的端口
[...]
decision_logs:
console: true
plugins:
envoy_ext_authz_grpc:
addr: ":9191" # This is the port where the envoy plugin will listen
path: mypackage/mysubpackage/myrule # Default path for grpc plugin
# Here you can add your own configuration with services and bundles
[...]
查看 Envoy 的授权服务文档，您可以看到消息具有以下属性
OkHttpResponse
{
"status": {...},
"denied_response": {...},
"ok_response": {
"headers": [],
"headers_to_remove": [],
"dynamic_metadata": {...},
"response_headers_to_add": [],
"query_parameters_to_set": [],
"query_parameters_to_remove": []
},
"dynamic_metadata": {...}
}
这意味着，根据 authz 服务器的响应，Envoy 可以添加或删除标头、查询参数，甚至更改响应状态。OPA 也可以做到这一点，如 OPA 文档 中所述。
测试
让我们测试简单的用法（授权），然后创建一个更高级的规则来展示如何使用 OPA 修改请求和响应。
部署一个应用程序来运行 curl 命令到 httpbin 示例应用程序
$ kubectl -n my-app run --image=curlimages/curl curl -- /bin/sleep 100d
应用第一个 Rego 规则并重新启动 OPA 部署
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
name: opa-policy
namespace: opa
data:
policy.rego: |
package mypackage.mysubpackage
import rego.v1
default myrule := false
myrule if {
input.attributes.request.http.headers["x-force-authorized"] == "enabled"
}
myrule if {
input.attributes.request.http.headers["x-force-authorized"] == "true"
}
EOF
$ kubectl rollout restart deployment -n opa
简单的情况是，如果请求包含标头 x-force-authorized 且其值为 enabled 或 true，则允许请求。如果标头不存在或具有其他值，则请求将被拒绝。
创建 Rego 规则有多种方法。在本例中，我们创建了两个不同的规则。按顺序执行，第一个满足所有条件的规则将是使用的规则。
简单规则
以下请求将返回 403
$ kubectl exec -n my-app curl -c curl -- curl -s -w "\nhttp_code=%{http_code}" httpbin:8000/get
以下请求将返回 200 和主体
$ kubectl exec -n my-app curl -c curl -- curl -s -w "\nhttp_code=%{http_code}" httpbin:8000/get -H "x-force-authorized: enabled"
高级操作
现在是更高级的规则。应用第二个 Rego 规则并重新启动 OPA 部署
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
name: opa-policy
namespace: opa
data:
policy.rego: |
package mypackage.mysubpackage
import rego.v1
request_headers := input.attributes.request.http.headers
force_unauthenticated if request_headers["x-force-unauthenticated"] == "enabled"
default allow := false
allow if {
not force_unauthenticated
request_headers["x-force-authorized"] == "true"
}
default status_code := 403
status_code := 200 if allow
status_code := 401 if force_unauthenticated
default body := "Unauthorized Request"
body := "Authentication Failed" if force_unauthenticated
myrule := {
"body": body,
"http_status": status_code,
"allowed": allow,
"headers": {"x-validated-by": "my-security-checkpoint"},
"response_headers_to_add": {"x-add-custom-response-header": "added"},
"request_headers_to_remove": ["x-force-authorized"],
"dynamic_metadata": {"my-new-metadata": "my-new-value"},
}
EOF
$ kubectl rollout restart deployment -n opa
在该规则中，您可以看到
myrule["allowed"] := allow # Notice that `allowed` is mandatory when returning an object, like here `myrule`
myrule["headers"] := headers
myrule["response_headers_to_add"] := response_headers_to_add
myrule["request_headers_to_remove"] := request_headers_to_remove
myrule["body"] := body
myrule["http_status"] := status_code
这些是将从 OPA 服务器返回到 Envoy 代理的值。Envoy 将使用这些值来修改请求和响应。
请注意，在返回 JSON 对象而不是仅返回 true/false 时，需要 allowed。这可以在 OPA 文档 中找到。
更改返回的主体
让我们测试新功能
$ kubectl exec -n my-app curl -c curl -- curl -s -w "\nhttp_code=%{http_code}" httpbin:8000/get
现在我们可以更改响应主体。对于 403，Rego 规则中的主体更改为“未授权请求”。使用前面的命令，您应该收到
Unauthorized Request
http_code=403
更改返回的主体和状态代码
使用标头 x-force-authorized: enabled 运行请求，您应该收到主体“身份验证失败”和错误“401”
$ kubectl exec -n my-app curl -c curl -- curl -s -w "\nhttp_code=%{http_code}" httpbin:8000/get -H "x-force-unauthenticated: enabled"
向请求添加标头
运行有效请求，您应该收到带有新标头 x-validated-by: my-security-checkpoint 和已删除的标头 x-force-authorized 的回显主体
$ kubectl exec -n my-app curl -c curl -- curl -s httpbin:8000/get -H "x-force-authorized: true"
向响应添加标头
运行相同的请求，但仅显示标头，您将找到在 Authz 检查期间添加的响应标头 x-add-custom-response-header: added
$ kubectl exec -n my-app curl -c curl -- curl -s -I httpbin:8000/get -H "x-force-authorized: true"
在过滤器之间共享数据
最后，您可以使用 dynamic_metadata 将数据传递给后续的 Envoy 过滤器。当您想要将数据传递到链中的另一个 ext_authz 过滤器或想要在应用程序日志中打印它时，这很有用。
为此，请查看您之前设置的访问日志格式
[...]
accessLogFormat: |
[OPA DEMO] my-new-dynamic-metadata: "%DYNAMIC_METADATA(envoy.filters.http.ext_authz)%"
[...]
DYNAMIC_METADATA 是一个保留关键字，用于访问元数据对象。其余的是您要访问的过滤器的名称。在本例中，名称 envoy.filters.http.ext_authz 由 Istio 自动创建。您可以通过转储 Envoy 配置来验证这一点
$ istioctl pc all deploy/httpbin -n my-app -oyaml | grep envoy.filters.http.ext_authz
您将看到过滤器的配置。
让我们测试动态元数据。在高级规则中，您正在创建一个新的元数据条目：{"my-new-metadata": "my-new-value"}。
运行请求并检查应用程序的日志
$ kubectl exec -n my-app curl -c curl -- curl -s -I httpbin:8000/get -H "x-force-authorized: true"
$ kubectl logs -n my-app deploy/httpbin -c istio-proxy --tail 1
您将在输出中看到由 OPA Rego 规则配置的新属性
[...]
my-new-dynamic-metadata: "{"my-new-metadata":"my-new-value","decision_id":"8a6d5359-142c-4431-96cd-d683801e889f","ext_authz_duration":7}"
[...]
结论
在本指南中，我们展示了如何集成 Istio 和 OPA 以对简单的微服务应用程序执行策略。我们还展示了如何使用 Rego 修改请求和响应属性。这是构建可供所有应用程序团队使用的平台级策略系统的基础示例。
