红帽全球峰会第 4 章 APIcast 策略
APIcast 策略是修改 APIcast 操作方式的功能单元。可以启用、禁用和配置策略，以控制它们如何修改 APIcast。使用策略添加默认 APIcast 部署中不可用的功能。您可以创建自己的策略，或使用 Red Hat 3scale 提供的标准策略。
以下主题提供有关标准 APIcast 策略的信息，创建您自己的自定义 APIcast 策略并创建策略链。
使用策略链控制服务策略。策略链执行以下操作：
- 指定 APIcast 使用的策略
- 为策略 3scale 提供配置信息
- 指定 3scale 加载策略的顺序
红帽 3scale 提供了一种添加自定义策略的方法，但不支持自定义策略。
要使用自定义策略修改 APIcast 的行为，您必须执行以下操作：
- 在 APIcast 中添加自定义策略
- 定义配置 APIcast 策略的策略链
- 将策略链添加到 APIcast
4.1. APIcast 标准策略
3scale 提供以下标准策略：
- 第 4.1.1 节 “3scale Auth 缓存策略”
- 第 4.1.2 节 “3scale 批处理器策略”
- 第 4.1.3 节 “匿名访问策略”
- 第 4.1.4 节 “CORS 请求处理策略”
- 第 4.1.5 节 “echo policy”
- 第 4.1.6 节 “边缘限制策略”
- 第 4.1.7 节 “标头修改策略”
- 第 4.1.8 节 “IP 检查策略”
- 第 4.1.9 节 “JWT 声明检查策略”
- 第 4.1.10 节 “liquid Context Debug 策略”
- 第 4.1.11 节 “日志记录策略”
- 第 4.1.12 节 “OAuth 2.0 令牌 Introspection 策略”
- 第 4.1.13 节 “Prometheus 指标”
- 第 4.1.14 节 “推荐策略”
- 第 4.1.15 节 “重试策略”
- 第 4.1.16 节 “RH-SSO/Keycloak 角色检查策略”
- 第 4.1.17 节 “路由策略”
- 第 4.1.18 节 “SOAP 策略”
- 第 4.1.19 节 “TLS 客户端证书验证策略”
- 第 4.1.20 节 “上游策略”
- 第 4.1.21 节 “上游连接策略”
- 第 4.1.22 节 “URL 重写策略”
- 第 4.1.23 节 “使用 Captures 策略的 URL 重写”
您可以在 3scale API Management 中 启用和配置 标准策略。
4.1.1. 3scale Auth 缓存策略
3scale 身份验证缓存策略会缓存对 APIcast 发出的身份验证调用。您可以选择操作模式来配置缓存操作。
3scale Auth 缓存在以下模式中可用：
1.Strict - Cache only authorized calls.
"strict"模式仅缓存授权的调用。如果策略在"strict"模式下运行，并且调用失败或被拒绝，策略会使缓存条目失效。如果后端无法访问，则所有缓存的调用都会被拒绝，无论它们缓存的状态如何。
2.Resilient – Authorize according to last request when backend is down.
"弹性"模式会缓存授权和拒绝调用。如果策略在"弹性"模式下运行，则失败的调用不会使现有的缓存条目无效。如果后端变得不可访问，则命中缓存的调用仍会根据缓存的状态继续获得授权或拒绝。
3.Allow - When backend is down, allow everything unless seen before and denied.
"Allow"模式会缓存授权和被拒绝的调用。如果策略在"allow"模式下运行，则缓存的调用根据缓存的状态继续被拒绝或允许。但是，任何新调用都将缓存为授权。
在"允许"模式下操作存在安全隐患。在使用"allow"模式时，请考虑以上问题并进行练习。
4.none - 禁用缓存。
"None"模式禁用缓存。如果您希望策略保持活动状态，但不想使用缓存，则此模式非常有用。
配置属性
| 属性 | 描述 | 值 | 必需？ |
|---|---|---|---|
| caching_type |
| 数据类型：枚举的字符串 [resilient, strict, allow, none] | 是 |
策略对象示例
有关如何配置策略的详情，请参考文档中的创建策略链 部分。
4.1.2. 3scale 批处理器策略
3scale Batcher 策略为标准 APIcast 授权机制提供了一个替代方法，其中每个 API 请求 APIcast 都会进行对 3scale 后端(Service Management API)的调用。
3scale Batcher 策略通过显著减少到 3scale 后端的请求数量来减少延迟并增加吞吐量。为了达到此目的，此策略会缓存授权状态和批处理使用情况报告。
当 3scale Batcher 策略被启用时，APIcast 会使用以下授权流：
在每个请求中，策略检查是否缓存凭证：
- 如果缓存了凭据，策略将使用缓存的授权状态，而不是调用 3scale 后端。
- 如果没有缓存凭据，策略会调用后端，并使用可配置的生存时间(TTL)来缓存授权状态。
- 策略不立即向 3scale 后端报告与请求对应的使用量，而是累计使用计数器将它们报告到批处理中的后端。单独的线程在单个调用中报告 3scale 后端的总用量计数器，具有可配置的频率。
3scale Batcher 策略提高了吞吐量，但准确性较低。使用限制和当前利用率存储在 3scale 中，APIcast 只能在向 3scale 后端发出调用时获取正确的授权状态。当 3scale Batcher 策略被启用时，chrony APIcast 不会发送调用 3scale。在此窗口中，调用的应用程序可能会超过定义的限值。
如果吞吐量比速率限制的准确性更重要，则将此策略用于高负载 API。当报告频率和授权 TTL 低于速率限制周期时，3scale Batcher 策略可以带来更好的准确性。例如，如果限制是每天的，并且报告频率和授权 TTL 被配置为几分钟。
3scale Batcher 策略支持以下配置设置：
auths_ttl：当授权缓存过期时，以秒为单位设置 TTL。当缓存当前调用的授权时，APIcast 将使用缓存的值。在
auths_ttl参数中设置的时间后，APIcast 会移除缓存并调用 3scale 后端来检索授权状态。-
batch_report_seconds：设置批处理报告的频率发送到 3scale 后端。默认值为10秒。
要使用此策略，请在策略链中同时启用 3scale APIcast 和 3scale 批处理器策略。
4.1.3. 匿名访问策略
匿名访问策略会公开一项服务，无需身份验证。例如，这对无法适应发送身份验证参数的传统应用程序很有用。匿名策略只支持使用 API Key 和 App Id / App Key 身份验证选项的服务。当为未提供任何凭证的 API 请求启用策略时，APIcast 将授权调用使用策略中配置的默认凭据。若要授权 API 调用，配置有凭据的应用必须存在并且处于活动状态。
使用 Application Plans，您可以配置用于默认凭证的应用程序的速率限值。
在策略链中同时使用这些策略时，您需要将匿名访问策略放在 APIcast 策略的前面。
以下是策略所需的配置属性：
auth_type ：从以下备选之一选择一个值，并确保属性与为 API 配置的身份验证选项对应：
- app_id_and_app_key ：用于 App ID / App Key 身份验证选项。
- user_key: 用于 API 密钥身份验证选项。
- app_id （仅适用于 app_id_and_app_key auth 类型）：如果没有通过 API 调用提供凭证，则将用于授权的应用程序 Id。
- app_key （仅适用于 app_id_and_app_key auth 类型）：如果没有通过 API 调用提供凭据，则应用程序的 App Key 用于授权。
- user_key （仅适用于 user_key auth_type）：如果没有通过 API 调用提供凭据，应用程序使用的 API 密钥将用于授权。
图 4.1. 匿名访问策略
4.1.4. CORS 请求处理策略
通过允许您指定以下指定来控制 CORS 行为，可通过交叉资源共享(CORS)请求处理策略来控制 CORS：
- 允许的标头
- 允许的方法
- 允许的凭证
- 允许的源标头
CORS 请求处理策略将阻止所有未指定的 CORS 请求。
当在策略链中使用这两个策略时，您需要将 CORS Request 处理策略放在 APIcast 策略的前面。
配置属性
| 属性 | 描述 | 值 | 必需？ |
|---|---|---|---|
| allow_headers |
| data type：字符串数组，必须是 CORS 标头 | 否 |
| allow_methods |
| data type：枚举字符串的数组 [GET, HEAD, POST, PUT, DELETE, PATCH, OPTIONS, TRACE, CONNECT] | 否 |
| allow_origin |
| 数据类型：字符串 | 否 |
| allow_credentials |
| 数据类型：布尔值 | 否 |
策略对象示例
有关如何配置策略的详情，请参考文档的创建策略链部分。
4.1.5. echo policy
Echo 策略将传入请求打印回客户端，以及可选的 HTTP 状态代码。
配置属性
| 属性 | 描述 | 值 | 必需？ |
|---|---|---|---|
| status | 回显策略将返回到客户端的 HTTP 状态代码 | 数据类型：整数 | 否 |
| exit |
指定回显策略将使用的退出模式。 | data type：枚举字符串 [request, set] | 是 |
策略对象示例
有关如何配置策略的详情，请参考文档的创建策略链部分。
4.1.6. 边缘限制策略
Edge Limiting 策略旨在为发送到后端 API 的流量提供灵活的速率限制，并可与默认的 3scale 授权一起使用。策略支持的用例的一些示例包括：
-
最终用户速率限制： Rate limits by the "sub"(subject)声明在请求的 Authorization 标头中传递的 JWT 令牌的值（配置为
{{ jwt.sub }}）。 - 请求每秒(RPS)速率限制.
- 每个服务的全球速率限值：每个服务应用限制而不是每个应用程序。
- 并发连接限制：设置允许的并发连接数。
4.1.6.1. 限制类型
该策略支持 lua-resty-limit-traffic 库提供的以下类型的限制：
-
leaky_bucket_limiters：基于基于基于平均请求数和最大突发大小的"leaky_bucket"算法。 -
fixed_window_limiters: 基于固定的时间窗口（最后 X 秒）。 -
connection_limiters：基于并发连接数。
您可以通过服务或全局限制来限制任何限制。
4.1.6.2. 限制定义
限制具有一个键，用于对用来定义限制（IP、服务、端点、ID、特定标头等）的实体进行编码。Key 在限制者的 key 参数中指定。
key 是由以下属性定义的对象：
-
名称：它是密钥的名称。它在范围内必须是唯一的。 Scope：它定义密钥的范围。支持的范围有：-
每个影响一个服务（
service）的服务范围。 -
影响所有服务（
global）的全局范围。
-
每个影响一个服务（
name_type: 它定义如何评估"name"值：-
纯文本（
plain） -
Liquid（
liquid）
-
纯文本（
每个限制也有一些参数因类型而异：
leaky_bucket_limiters:rate,burst.-
速率：它定义每秒可进行的请求数量，而没有延迟。 -
burst：它定义每秒可以超过允许的速率的请求数。对于超过允许率（根据速率指定）的请求引入人工延迟。在超过burst中定义的每秒请求数后，请求将被拒绝。
-
-
fixed_window_limiters:count,window.计数定义了在窗口中定义的每秒数发出的请求数量。 connection_limiters：conn、burst、delay.-
conn：定义允许的最大并发连接数。它允许通过每秒burst连接超过该数量。 -
delay：这是延迟超过限制的连接的秒数。
-
例子
每分钟允许 10 个请求到 service_A：
{ "key": { "name": "service_A" }, "count": 10, "window": 60 }{ "key": { "name": "service_A" }, "count": 10, "window": 60 }Copy to Clipboard Copied! Toggle word wrap Toggle overflow 允许延迟 1 到 10 的 100 个连接，延迟为 10：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
您可以为每个服务定义多个限制。如果定义了多个限制，则在至少达到一个限值时请求可以被拒绝或延迟。
4.1.6.3. 移动模板
Edge Limiting 策略允许通过在键中支持 Liquid 变量来指定动态密钥的限制。为此，键的 name_type 参数必须设置为 "liquid"，而 name 参数则可使用 Liquid 变量。示例：{ { remote_addr }} 用于客户端 IP 地址，或者 {{ jwt.sub }} 用于 JWT 令牌的"sub"声明。
例如：
{
"key": { "name": "{{ jwt.sub }}", "name_type": "liquid" },
"count": 10,
"window": 60
}
{
"key": { "name": "{{ jwt.sub }}", "name_type": "liquid" },
"count": 10,
"window": 60
}有关 Liquid 支持的详情请参考 第 5.1 节 “在策略中使用变量和过滤器”。
4.1.6.4. 应用条件
该条件定义 API 网关何时应用限制器。您必须在每个限制器的 condition 属性中至少指定一个操作。
condition 由以下属性定义：
-
combine_op.它是应用于操作列表的布尔值运算符。支持以下两个值：或和。 操作。它是需要评估的条件列表。每个操作都由一个具有以下属性的对象表示：-
left：操作的左侧。 -
left_type：如何评估左属性（解释或静止）。 -
正确：操作的正确部分。 -
right_type：如何评估正确的属性（解释或查询）。 -
op：在左侧和右部分之间应用的 Operator。支持以下两个值：==(等于)和!=（不等于）。
-
例如：
4.1.6.5. 配置存储
默认情况下，Edge 限制策略将 OpenResty 共享字典用于速率限制计数器。但是，可以使用外部 Redis 服务器而不是共享字典。这在使用多个 APIcast 实例时很有用。Redis 服务器可以使用 redis_url 参数进行配置。
4.1.6.6. 错误处理
限制器支持以下参数来配置错误的处理方式：
limits_exceeded_error：允许配置在超过配置的限制时将返回到客户端的错误状态代码和消息。应配置以下参数：-
status_code：超过限制时请求的状态代码。默认：429。 error_handling: 指定如何使用以下选项处理错误：-
退出：停止处理请求并返回错误消息。 -
日志：完成处理请求并返回输出日志。
-
-
configuration_error：允许配置在配置不正确时返回到客户端的错误状态代码和消息。应配置以下参数：-
status_code：配置问题时的状态代码。默认：500。 error_handling: 指定如何使用以下选项处理错误：-
退出：停止处理请求并返回错误消息。 -
日志：完成处理请求并返回输出日志。
-
-
4.1.7. 标头修改策略
标头修改策略允许您修改现有标头，或者定义额外的标头以添加到或从传入的请求或响应中删除。您可以修改响应和请求标头。
Header 修改策略支持以下配置参数：
-
request: 应用到请求标头的操作列表 -
响应：应用到响应标头的操作列表
每个操作都由以下参数组成：
-
op：指定要应用的操作。add操作会为现有标头添加一个值。这个set操作会创建一个标头和值，如果已存在该标头的值，则会覆盖现有的标头值。push操作会创建一个标头和值，但如果已存在，则不会覆盖现有的标头值。相反，push会将值添加到现有标头中。delete操作会删除标头。 -
标题：指定要创建的标头或修改，并且可以用作标头名称（如Custom-Header）的任何字符串。 -
value_type：定义如何评估标题值，可以是纯文本的纯文本或作为 Liquid 模板进行评估。更多信息请参阅 第 5.1 节 “在策略中使用变量和过滤器”。 -
值：指定将用于标头的值。对于值类型"liquid"，值应当采用{{ variable_from_context }}格式。删除时不需要.
策略对象示例
有关如何配置策略的详情，请参考文档中的创建策略链 部分。
4.1.8. IP 检查策略
IP 检查策略用于根据 IP 列表拒绝或允许请求。
配置属性
| 属性 | 描述 | 数据类型 | 必需？ |
|---|---|---|---|
| check_type |
|
字符串，必须是 | 是 |
| ips |
| 字符串数组，必须是有效的 IP 地址 | 是 |
| error_msg |
| 字符串 | 否 |
| client_ip_sources |
|
字符串数组，有效选项为 | 否 |
策略对象示例
有关如何配置策略的详情，请参考文档的创建策略链部分。
4.1.9. JWT 声明检查策略
4.1.9.1. 关于 JWT 申索检查策略
JWT 声明基于 JSON Web Token(JWT)声明，您可以通过定义新规则来阻止资源目标和方法。
为了基于 JWT 声明的值进行路由，您需要链中的策略验证 JWT，并将声明存储在策略共享的上下文中。
如果 JWT Claim Check 策略正在阻止资源和方法，该策略也会验证 JWT 操作。另外，如果方法资源不匹配，则请求将继续至后端 API。
示例：如果 GET 请求，如果不是请求，则 JWT 需要以 admin 身份具有角色声明。另一方面，任何非 GET 请求都不会验证 JWT 操作，因此允许 POST 资源而无需 JWT 约束。
4.1.9.2. 在策略链中配置 JWT 声明检查策略
4.1.9.2.1. 先决条件：
- 您需要有权访问 3scale 安装。
- 您需要等待所有部署完成。
4.1.9.2.2. 配置策略
- 要将 JWT Claim Check 策略添加到您的 API，请按照 启用标准策略中介绍的步骤操作， 然后选择 JWT Claim Check。
- 单击 JWT 声明检查 链接。
- 若要启用该策略，选中 Enabled 复选框。
-
若要添加规则，可单击加号
+图标。 - 指定 resource_type。
- 选择 operator。
- 指明规则控制的资源。
-
要添加允许的方法，请单击加号
+图标。 - 键入错误消息，以便在流量被阻止时向用户显示。
- 使用 JWT Claim Check 设置完 API 后，单击 Update Policy。
另外：
-
单击对应部分中的加号
+图标，您可以添加更多资源类型和允许的方法。
要保存更改，请点击 Update & test in Staging Environment。
4.1.10. liquid Context Debug 策略
Liquid Context Debug 策略仅用于开发环境中而不是生产环境中的调试用途。
此策略使用 JSON 响应 API 请求，其包含上下文中可用的对象和值，并可用于评估 Liquid 模板。当与 3scale APIcast 或 Upstream 策略结合使用时，必须在策略链中放置 Liquid Context Debug 才能正常工作。为避免循环引用，该策略仅包含重复的对象，并将其替换为 stub 值。
启用策略时 APIcast 返回的值示例：
4.1.11. 日志记录策略
Logging 策略允许单独启用或禁用 APIcast(NGINX)访问日志。默认情况下，策略链中不启用此策略。
此策略仅支持 enable_access_logs 配置参数。要禁用服务的访问日志记录，启用策略，取消选择 enable_access_logs 参数，然后单击 Submit 按钮。要启用访问日志，请选择 enable_access_logs 参数或禁用 Logging 策略。
您可以将 Logging 策略与访问日志位置的全局设置合并。设置 APICAST_ACCESS_LOG_FILE 环境变量，以配置 APIcast 访问日志的位置。默认情况下，此变量设置为 /dev/stdout，这是标准输出设备。有关全局 APIcast 参数的详情，请参考 ???。
4.1.12. OAuth 2.0 令牌 Introspection 策略
OAuth 2.0 Token Introspection 策略允许使用令牌签发者(Red Hat Single Sign-On)的 Token Introtion Endpoint(Red Hat Single Sign-On)验证选项来验证用于通过 OpenID Connect(OIDC)身份验证选项的 JSON Web Token Token 令牌(JWT)令牌。
APIcast 支持 auth_type 字段中的以下身份验证类型，以确定 Token Introspection Endpoint 和调用此端点时使用的凭证 APIcast：
-
use_3scale_oidc_issuer_endpoint: APIcast 使用客户端凭证、客户端 ID 和客户端 Secret，以及来自 Service Integration 页面中配置的 OIDC 签发者设置的 Token Introspection Endpoint。APIcast 从token_introspection_endpoint字段发现 Token Introspection 端点。此字段位于 OIDC 签发者返回的.well-known/openid-configuration端点中。
例 4.1. 身份验证类型设置为 use_3scale_oidc_issuer_endpoint
client_id+client_secret:此选项允许您指定不同的令牌内省端点，以及客户端 ID 和客户端 Secret APIcast 用来请求令牌信息。使用这个选项时，请设置以下配置参数：-
client_id：为令牌内省端点设置客户端 ID。 -
client_secret：为令牌内省端点设置客户端 Secret。 -
introspection_url：设置 Introspection Endpoint URL。
-
例 4.2. 身份验证类型设置为 client_id+client_secret
无论 auth_type 字段中的设置是什么，APIcast 使用 Basic Authentication 来授权 Token Introspection 调用（Authorization: Basic <token> 标头，其中 <token > ; 是 Base64 编码的 < client_id>:<client_secret>）。
Token Introspection Endpoint 的响应中包含 active 属性。APIcast 检查此属性的值。根据属性的值，APIcast 授权或拒绝调用：
-
true：调用已被授权 -
false: 调用被拒绝，且Authentication Failed错误
该策略允许缓存令牌，以避免在相同 JWT 令牌的每个调用中调用 Token Introspection Endpoint。要为 Token Introspection Policy 启用令牌缓存，请将 max_cached_tokens 字段设置为从 0 （禁用该功能）到 10000 直接的值。另外，您可以在 max_ttl_tokens 字段中将令牌的值从 1 设置为 3600 秒。
4.1.13. Prometheus 指标
Prometheus是一个独立的开源系统监视和警报工具包。
在这个 Red Hat 3scale 版本中，不支持 Prometheus 安装和配置。另外，您可以使用 Prometheus 的社区版本 视觉化 API 服务的指标和警报。
Prometheus 指标可用性
以下部署选项提供了与 Prometheus 的 APIcast 集成：
- 自我管理的 APIcast（包括托管或内部 API 管理器）
- 内置 APIcast 内部
托管 API Manager 和托管的 APIcast 不提供与 Prometheus 的 APIcast 集成。
Prometheus metrics 列表
以下指标始终可用：
| 指标 | 描述 | 类型 | 标签 |
|---|---|---|---|
| nginx_http_connections | HTTP 连接数 | gauge | state(accepted,active,handled,reading,total,waiting,writing) |
| nginx_error_log | APIcast 错误 | 计数 | level(debug,info,notice,warn,error,crit,alert,emerg) |
| openresty_shdict_capacity | worker 共享字典的能力 | gauge | dict(one for every dictionary) |
| openresty_shdict_free_space | worker 共享字典的可用空间 | gauge | dict(one for every dictionary) |
| nginx_metric_errors_total | 管理指标的 Lua 库错误数 | 计数 | - |
| total_response_time_seconds | 发送响应客户端所需时间（以秒为单位）
注： 要访问 | histogram | service_id, service_system_name |
| upstream_response_time_seconds | 来自上游服务器的响应时间（以秒为单位）
注： 要访问 | histogram | service_id, service_system_name |
| upstream_status | 来自上游服务器的 HTTP 状态
注： 要访问 | 计数 | status, service_id, service_system_name |
| threescale_backend_calls | 授权并报告请求到 3scale 后端(Apisonator) | 计数 | endpoint(authrep, auth, report), status(2xx, 4xx, 5xx) |
只有在使用 3scale Batcher 策略时，以下指标才可用：
| 指标 | 描述 | 类型 | 标签 |
|---|---|---|---|
| batching_policy_auths_cache_hits | 按 3scale 批处理策略的 auths 缓存中的内容 | 计数 | - |
| batching_policy_auths_cache_misses | 3scale 批处理策略的 auths 缓存中丢失 | 计数 | - |
没有值的指标
如果指标没有值，则指标会被隐藏。例如，如果 nginx_error_log 没有报告错误，则不会显示 nginx_error_log 指标。只有当它的值有值后才可见。
4.1.14. 推荐策略
请参阅 请参阅 请参阅 请参阅 请参阅器过滤功能。当在服务策略链中启用策略时，APIcast 会在 引用 参数中将后续请求的引用策略发送到 Service Management API（AuthRep 调用）。有关如何过滤工作的更多信息，请参阅 身份验证模式 中的" 引用器过滤 "部分。
器
4.1.15. 重试策略
重试策略将请求数设置为上游 API。重试策略是为每个服务配置的，因此用户可以根据需要为任意数量或任意数量的服务启用重试，并为不同的服务配置不同的重试值。
自 3scale 2.6 起，无法配置可从策略中重试的情况。这通过环境变量 APICAST_UPSTREAM_RETRY_CASES 控制，后者将重试请求应用到所有服务。有关此内容，请查看 APICAST_UPSTREAM_RETRY_CASES。
重试策略 JSON 的示例如下所示：
4.1.16. RH-SSO/Keycloak 角色检查策略
此策略在与 OpenID Connect 身份验证选项一起使用时添加角色检查。此策略验证红帽单点登录(RH-SSO)中发布的访问令牌中的域角色和客户端角色。当您要向 3scale 的每个客户端资源添加角色检查时，会指定 realm 角色。
有两种类型的角色检查策略配置中指定的 type 属性：
- 白名单 （默认）：当使用 白名单 时，APIcast 将检查 JWT 令牌中是否存在指定的范围，并在 JWT 中没有范围时拒绝调用。
- blacklist ：当使用 黑名单 时，如果 JWT 令牌包含黑名单范围，APIcast 将拒绝调用。
无法同时配置检查 - 在同一 策略中的黑名单 和 白名单，但您可以在 APIcast 策略链中添加多个 RH-SSO/Keycloak 角色检查 策略的实例。
您可以通过策略配置的 scopes 属性配置范围列表。
每个 scope 对象具有以下属性：
- 资源 ：角色控制的资源（端点）。这个格式与映射规则相同。模式从字符串开头匹配，若要完全匹配，您必须在末尾附加 $。
resource_type ：这定义了 资源 值的评估方式。
- 以纯文本(plain)形式：以纯文本形式评估 资源 值。示例： /api/v1/products$.
- 作为 Liquid 文本(liquid)：允许在 资源 值中使用 Liquid。示例： /resource_{{ jwt.aud }} 管理对包含客户端 ID 的资源的访问。
方法 ：使用此参数根据 RH-SSO 中的用户角色，列出 APIcast 中允许的 HTTP 方法。例如，您可以允许使用以下方法：
-
用于访问
/resource1的role1realm 角色。对于没有此 realm 角色的方法，您需要指定 黑名单。 -
client1角色调用role1来访问/resource1。 -
用于访问
/resource1的role1和role2域角色。指定 realm_roles 中的角色。您还可以指定各个角色的范围。 -
应用客户端的
role1角色 （这是访问令牌的接收者）来访问/resource1。使用liquid客户端类型向客户端指定 JSON Web Token(JWT)信息。 -
客户端角色，包括应用客户端的客户端 ID（访问令牌的接收者）来访问
/resource1。使用liquid客户端类型，将 JWT 信息指定为客户端角色的name。 -
名为
role1的客户端角色，以访问资源，包括应用客户端 ID。使用liquid客户端类型为resource指定 JWT 信息。
-
用于访问
realm_roles ：使用它来检查 realm 角色（请参阅 Red Hat Single Sign-On 文档中的 Realm Roles ）。
域角色存在于红帽单点登录发布的 JWT 中。
"realm_access": { "roles": [ "<realm_role_A>", "<realm_role_B>" ] }"realm_access": { "roles": [ "<realm_role_A>", "<realm_role_B>" ] }Copy to Clipboard Copied! Toggle word wrap Toggle overflow 策略中必须指定实际角色。
"realm_roles": [ { "name": "<realm_role_A>" }, { "name": "<realm_role_B>" } ]"realm_roles": [ { "name": "<realm_role_A>" }, { "name": "<realm_role_B>" } ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下是 realm_roles 数组中每个对象的可用属性：
- name ：指定角色的名称。
- name_type ：定义必须如何评估名称；它可以是 纯 的 或 liquid （与 resource_type的相同）。
client_roles ：使用 client_roles 检查客户端命名空间中的特定访问角色（请参阅 Red Hat Single Sign-On 文档中的客户端角色 ）。
客户端角色存在于 JWT 中的 resource_access 声明下。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 指定策略中的客户端角色。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下是 client_roles 数组中每个对象的可用属性：
- name ：指定角色的名称。
- name_type ：定义必须如何评估 name 值；它可以是 纯 的 或 liquid （与 resource_type的相同）。
- client ：指定角色的客户端。如果未定义，此策略将 aud 声明用作客户端。
- client_type ：定义必须如何评估 客户端 值；它可以是 纯 的或禁止（与 resource_type的作用相同）。
4.1.17. 路由策略
Routing 策略允许您将请求路由到不同的目标端点。您可以定义目标端点，然后将从 UI 传入的请求路由到使用正则表达式的请求。
路由基于以下规则：
与 APIcast 策略组合时，路由策略应放在链中的 APIcast 之前，因为首先将内容输出到响应的两个策略。当第二个进程获得更改以运行其内容阶段时，该请求已发送到客户端，因此不会输出到响应。
4.1.17.1. 路由规则
- 如果存在多个规则，路由策略会应用第一个匹配项。您可以对这些规则进行排序。
- 如果没有规则匹配，策略不会更改上游，并使用服务配置中定义的已定义的私有基本 URL。
4.1.17.2. 请求路径规则
这是当路径为 /accounts 时路由到 http://example.com 的配置：
4.1.17.3. 标头规则
这是当标头 Test-Header 的值为 123 时路由到 http://example.com 的配置：
4.1.17.4. 查询参数规则
这是当查询参数 test_query_arg 为 123 时路由到 http://example.com 的配置 ：
4.1.17.5. JWT 声明规则
若要基于 JWT 声明的值进行路由，链中需要有一个策略来验证 JWT 并将其存储在策略共享的上下文中。
这是当 JWT 声明 test_claim 的值为 123 时路由到 http://example.com 的配置 ：
4.1.17.6. 多操作规则
规则可以有多个操作，只有当所有上游评估为 true 时（使用 'and' combine_op）或至少被评估为 true （使用 'or' combine_op）指向给定上游的操作。combine_op 的默认值为 'and'。
这是在请求的路径为 /accounts 以及标头 Test-Header 的值为 123 时路由到 http://example.com 的配置：
这是在请求的路径为 /accounts 或者标头 Test-Header 的值为 123 时路由到 http://example.com 的配置 ：
4.1.17.7. 组合规则
规则可以组合在一起使用。当有多个规则时，上游选择是首批评估为 true 的规则之一。
这是包含多个规则的配置：
4.1.17.8. catch-all 规则
没有操作的规则始终匹配。这对于定义概括性规则非常有用。
如果路径为 /abc，则此配置将请求路由到 http://some_upstream.com，如果路径是 /def，将请求路由到 http://another_upstream.com，最后，如果之前的规则没有评估为 true，则会将请求路由到 http://default_upstream.com ：
4.1.17.9. 支持的操作
支持的操作有 ==, != 和 matches。后者将字符串与正则表达式匹配，并使用 ngx.re.match来实施
这是使用 != 的配置。当路径不是 /accounts 时，它会路由到 http://example.com:
4.1.17.10. 移动模板
可以将弹性模板用于配置的值。如果链中的策略将键 my_var 存储在上下文中，则可以使用动态值定义规则。
这是使用该值路由请求的配置：
4.1.17.11. 设置 Host 标头中使用的主机
默认情况下，当路由请求时，策略使用匹配的规则的 URL 主机设置 Host 标头。可以通过 host_header 属性指定不同的主机。
这是将 some_host.com 指定为 Host 标头主机的配置：
4.1.18. SOAP 策略
SOAP 策略与 HTTP 请求的 SOAPAction 或 Content-Type 标头中提供的 SOAP 操作 URI 匹配策略中指定的映射规则。
配置属性
| 属性 | 描述 | 值 | 必需？ |
|---|---|---|---|
| pattern |
此 | 数据类型：字符串 | 是 |
| metric_system_name |
| 数据类型：字符串，必须是一个有效的 metric | 是 |
策略对象示例
有关如何配置策略的详情，请参考文档的创建策略链部分。
4.1.19. TLS 客户端证书验证策略
4.1.19.1. 关于 TLS 客户端证书验证策略
借助 TLS 客户端证书验证策略，APIcast 实施 TLS 握手，并根据白名单验证客户端证书。白名单包含由认证机构(CA)或纯客户端证书签名的证书。如果证书过期或无效，请求将被拒绝，且不会处理其他策略。
客户端连接到 APIcast 以发送请求并提供客户端证书。APIcast 根据策略配置验证传入请求中提供的证书的真实性。APIcast 也可以配置为使用自己的客户端证书，以在连接到上游时使用它。
4.1.19.2. 设置 APIcast 以使用 TLS 客户端证书验证
APIcast 需要配置为终止 TLS。按照以下步骤配置用户在 APIcast 上提供的客户端证书验证策略。
4.1.19.2.1. 先决条件：
- 您需要有权访问 3scale 安装。
- 您需要等待所有部署完成。
4.1.19.2.2. 设置 APIcast 以使用策略
要设置 APIcast 并将其配置为终止 TLS，请按照以下步骤操作：
您需要获取访问令牌并部署 APIcast 自我管理，如 使用 OpenShift 模板部署 APIcast 中所述。
注意需要 APIcast 自我管理的部署，因为 APIcast 实例需要重新配置，才能将一些证书用于整个网关。
仅用于测试目的，您可以使用没有缓存和暂存环境以及
--param标志的 lazy 加载器来进行测试。oc new-app -f https://raw.githubusercontent.com/3scale/3scale-amp-openshift-templates/2.6.0.GA/apicast-gateway/apicast.yml --param CONFIGURATION_LOADER=lazy --param DEPLOYMENT_ENVIRONMENT=staging --param CONFIGURATION_CACHE=0
oc new-app -f https://raw.githubusercontent.com/3scale/3scale-amp-openshift-templates/2.6.0.GA/apicast-gateway/apicast.yml --param CONFIGURATION_LOADER=lazy --param DEPLOYMENT_ENVIRONMENT=staging --param CONFIGURATION_CACHE=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 生成证书用于测试目的。另外，对于生产部署，您可以使用证书颁发机构提供的证书。
使用 TLS 证书创建 Secret
oc create secret tls apicast-tls --cert=ca/certs/server.crt --key=ca/keys/server.key
oc create secret tls apicast-tls --cert=ca/certs/server.crt --key=ca/keys/server.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在 APIcast 部署中挂载 Secret
oc set volume dc/apicast --add --name=certificates --mount-path=/var/run/secrets/apicast --secret-name=apicast-tls
oc set volume dc/apicast --add --name=certificates --mount-path=/var/run/secrets/apicast --secret-name=apicast-tlsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将 APIcast 配置为为 HTTPS 开始侦听端口 8443
oc set env dc/apicast APICAST_HTTPS_PORT=8443 APICAST_HTTPS_CERTIFICATE=/var/run/secrets/apicast/tls.crt APICAST_HTTPS_CERTIFICATE_KEY=/var/run/secrets/apicast/tls.key
oc set env dc/apicast APICAST_HTTPS_PORT=8443 APICAST_HTTPS_CERTIFICATE=/var/run/secrets/apicast/tls.crt APICAST_HTTPS_CERTIFICATE_KEY=/var/run/secrets/apicast/tls.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在服务中公开 8443
oc patch service apicast -p '{"spec":{"ports":[{"name":"https","port":8443,"protocol":"TCP"}]}}'oc patch service apicast -p '{"spec":{"ports":[{"name":"https","port":8443,"protocol":"TCP"}]}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除默认路由
oc delete route api-apicast-staging
oc delete route api-apicast-stagingCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
apicast服务作为路由公开oc create route passthrough --service=apicast --port=https --hostname=api-3scale-apicast-staging.$WILDCARD_DOMAIN
oc create route passthrough --service=apicast --port=https --hostname=api-3scale-apicast-staging.$WILDCARD_DOMAINCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您要使用的每个 API 和每个 API 的域更改都需要这一步。
通过在占位符中指定 [Your_user_key]，验证之前部署的网关是否正常工作并且配置已保存。
curl https://api-3scale-apicast-staging.$WILDCARD_DOMAIN?user_key=[Your_user_key] -v --cacert ca/certs/ca.crt
curl https://api-3scale-apicast-staging.$WILDCARD_DOMAIN?user_key=[Your_user_key] -v --cacert ca/certs/ca.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.19.3. 在策略链中配置 TLS 客户端证书验证
4.1.19.3.1. 先决条件
- 您需要 3scale 登录凭据。
- 您需要使用 TLS Client Certificate Validation 策略配置 APIcast。
4.1.19.3.2. 配置策略
- 要将 TLS 客户端证书验证策略添加到您的 API，请按照 启用标准策略中介绍的步骤操作， 然后选择 TLS 客户端证书验证。
- 单击 TLS 客户端证书验证 链接。
- 若要启用该策略，选中 Enabled 复选框。
-
若要添加证书到白名单，可单击加号
+图标。 -
指定包括
-----BEGIN CERTIFICATE-----和-----END CERTIFICATE-----的证书。 - 使用 TLS 客户端证书验证设置完 API 后，单击 Update Policy。
另外：
-
您可以通过单击加号
+图标来添加更多证书。 - 您还可以通过单击上下箭头来重新组织证书。
要保存更改，请点击 Update & test in Staging Environment。
4.1.19.4. 验证 TLS 客户端证书验证策略的功能
4.1.19.4.1. 先决条件：
- 您需要 3scale 登录凭据。
- 您需要使用 TLS Client Certificate Validation 策略配置 APIcast。
4.1.19.4.2. 验证策略功能
您可以通过在占位符中指定 [Your_user_key] 来验证应用的策略。
curl https://api-3scale-apicast-staging.$WILDCARD_DOMAIN\?user_key\=[Your_user_key] -v --cacert ca/certs/ca.crt --cert ca/certs/client.crt --key ca/keys/client.key curl https://api-3scale-apicast-staging.$WILDCARD_DOMAIN\?user_key\=[Your_user_key] -v --cacert ca/certs/ca.crt --cert ca/certs/server.crt --key ca/keys/server.key curl https://api-3scale-apicast-staging.$WILDCARD_DOMAIN\?user_key\=[Your_user_key] -v --cacert ca/certs/ca.crt
curl https://api-3scale-apicast-staging.$WILDCARD_DOMAIN\?user_key\=[Your_user_key] -v --cacert ca/certs/ca.crt --cert ca/certs/client.crt --key ca/keys/client.key
curl https://api-3scale-apicast-staging.$WILDCARD_DOMAIN\?user_key\=[Your_user_key] -v --cacert ca/certs/ca.crt --cert ca/certs/server.crt --key ca/keys/server.key
curl https://api-3scale-apicast-staging.$WILDCARD_DOMAIN\?user_key\=[Your_user_key] -v --cacert ca/certs/ca.crt4.1.19.5. 从白名单中删除证书
4.1.19.5.1. 先决条件
- 您需要 3scale 登录凭据。
- 您需要使用 TLS 客户端证书验证策略设置 APIcast。
- 您需要通过在 策略链中配置 TLS 客户端证书验证将证书 添加到白名单。
4.1.19.5.2. 删除证书
- 单击 TLS 客户端证书验证 链接。
-
要从白名单中删除证书，请点击
x图标。 - 删除证书后，点击 Update Policy。
要保存更改，请点击 Update & test in Staging Environment。
4.1.19.6. 参考材料
有关使用证书的更多信息，请参阅 红帽认证系统。
4.1.20. 上游策略
通过 Upstream 策略，您可以使用正则表达式来解析主机请求标头，并将私有基本 URL 中定义的上游 URL 替换为不同的 URL。
例如：
具有 regex /foo 的策略和 URL 字段 newexample.com 将 URL https://www.example.com/foo/123/ 替换为 newexample.com
策略链参考：
| 属性 | 描述 | 值 | 必需？ |
|---|---|---|---|
| regex |
| 数据类型：字符串，必须是一个有效的正则表达式语法 | 是 |
| url |
使用 | 数据类型：字符串，确定这是有效的 URL | 是 |
策略对象示例
有关如何配置策略的详情，请参考文档的创建策略链部分。
4.1.21. 上游连接策略
4.1.21.1. 关于上游连接策略
根据您在 3scale 安装中配置 API 后端服务器的方式，为每个 API 更改以下指令的默认值：
-
proxy_connect_timeout -
proxy_send_timeout -
proxy_read_timeout
4.1.21.2. 在策略链中配置上游连接
4.1.21.2.1. 先决条件：
- 您需要有权访问 3scale 安装。
- 您需要等待所有部署完成。
4.1.21.2.2. 配置策略
- 要将 Upstream 连接策略添加到 API，请按照 启用标准 策略中的步骤操作并选择 Upstream 连接。
- 点 上游连接 链接。
- 若要启用该策略，选中 Enabled 复选框。
配置与上游连接的选项：
- send_timeout
- connect_timeout
- read_timeout
- 当您完成使用 Upstream 连接设置 API 后，点 Update Policy。
要保存更改，请点击 Update & test in Staging Environment。
4.1.22. URL 重写策略
URL 重写策略允许您修改请求的路径和查询字符串。
当与 3scale APIcast 政策结合使用时，如果将 URL 重新编写策略放在策略链中的 3scale APIcast 策略之前，APIcast 映射规则将应用到修改后的路径。如果在策略链中将 URL 重新写入策略放在 APIcast 下，则映射规则将应用到原始路径。
该策略支持以下两组操作：
-
命令：用于重写请求路径的命令列表。 -
query_args_commands：要应用的命令列表来重写请求的查询字符串。
4.1.22.1. 重写路径的命令
以下是 commands 列表中每个命令的配置参数，其中包括：
-
op:要应用的操作。可用的选项包括：sub和gsub。sub操作仅用您指定的正则表达式替换第一个匹配项。gsub操作会将所有匹配项替换为您指定的正则表达式。请参阅有关 sub 和 gsub 操作的文档。 -
正则表达式：要匹配的与 Perl 兼容的正则表达式。 -
替换：替换在匹配项中使用的 : 替换字符串。 -
Options（可选）：定义正则表达式的执行方式
的选项。有关可用选项的详情，请查看 OpenResty Lua 模块项目文档中的 ngx.re.match 部分。 -
break（可选）：如果将设置为 true（已启用）时，如果命令重新编写了 URL，它将是最后应用的一个（将丢弃列表中的所有 posterior 命令）。
4.1.22.2. 重写查询字符串的命令
以下是 query_args_commands 列表中每个命令由以下部分组成的配置参数：
op: 操作要应用到查询参数。可用的选项如下：-
添加: 为现有参数添加一个值。 -
设置：在未设置时创建 arg，并在设置时替换其值。 -
push：在未设置时创建 arg，并在设置时添加值。 -
删除：删除 arg。
-
-
ARG：用于操作的查询参数名称。 -
值：指定用于查询参数的值。对于值类型"liquid"，值应当采用{{ variable_from_context }}格式。对于delete操作，不考虑该值。 -
value_type（可选）：定义查询参数值的评估方式，可以是纯文本的纯文本，或者作为 Liquid 模板进行评估。更多信息请参阅 第 5.1 节 “在策略中使用变量和过滤器”。如果没有指定，则默认使用类型"plain"。
示例
URL 重写策略配置如下：
发送到 APIcast 的原始请求 URI：
https://api.example.com/api/v1/products/123/details?user_key=abc123secret&pusharg=first&setarg=original
https://api.example.com/api/v1/products/123/details?user_key=abc123secret&pusharg=first&setarg=original应用 URL 重写后 APIcast 发送到 API 后端的 URI：
https://api-backend.example.com/internal/products/123/details?pusharg=first&pusharg=pushvalue&setarg=setvalue
https://api-backend.example.com/internal/products/123/details?pusharg=first&pusharg=pushvalue&setarg=setvalue应用以下转换：
-
子字符串
/api/v1/匹配唯一的路径重写命令，它被/internal/替换。 -
已删除
user_key查询参数。 -
值
pushvalue作为pusharg查询参数的额外值添加。 -
查询参数
setarg的original值替换为配置的值setvalue。 -
命令
add没有被应用，因为原始 URL 中不存在查询参数addarg。
有关如何配置策略的详情，请参考文档中的创建策略链 部分。
4.1.23. 使用 Captures 策略的 URL 重写
使用 Captures 策略的 URL Rewriting 是 第 4.1.22 节 “URL 重写策略” 策略的替代，并允许在将 API 请求传递给 API 后端前重写 API 请求的 URL。
URL 使用 Captures 策略检索 URL 中的参数，并在重写 URL 中使用其值。
该策略支持 transformations 配置参数。这是一个对象列表，用于描述将哪些转换应用到请求 URL。每个调整对象由两个属性组成：
-
match_rule：此规则与传入请求 URL 匹配。它可以包含{nameOfArgument}格式的命名参数；这些参数可以在重写 URL 中使用。将 URL 与match_rule进行比较，作为正则表达式。匹配指定参数的值必须只包含以下字符（在 PCRE regex 表示法中）：[\w-.~%!$&'（）*+,;=@:]+。可以在match_rule表达式中使用其他 regex 令牌，如^表示字符串开头，$代表字符串末尾。 -
模板：原始 URL 重写的 URL 模板；它可以使用match_rule中的命名参数。
原始 URL 的查询参数与 template 中指定的查询参数合并。
示例
使用 Captures 的 URL 重写如下：
发送到 APIcast 的原始请求 URI：
https://api.example.com/api/v1/products/123/details?user_key=abc123secret
https://api.example.com/api/v1/products/123/details?user_key=abc123secret应用 URL 重写后 APIcast 发送到 API 后端的 URI：
https://api-backend.example.com/internal/products/details?user_key=abc123secret&extraparam=anyvalue&id=123
https://api-backend.example.com/internal/products/details?user_key=abc123secret&extraparam=anyvalue&id=123
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}