请求头和路由控制

此任务演示如何使用策略适配器来操作请求头和路由。

开始之前

  • 遵循安装指南中的说明在 Kubernetes 集群上安装 Istio 。

必须 在你的集群上启用策略检查。请按照启用策略检查中的步骤操作,以确保启用了策略检查 。

  • 按照 ingress 任务中的设置说明,使用 Gateway 配置 ingress。

  • httpbin 服务定义一个包含两条路由规则的 virtual service,以接收来自路径 /headers/status 的请求:

  1. $ kubectl apply -f - <<EOF
  2. apiVersion: networking.istio.io/v1alpha3
  3. kind: VirtualService
  4. metadata:
  5. name: httpbin
  6. spec:
  7. hosts:
  8. - "*"
  9. gateways:
  10. - httpbin-gateway
  11. http:
  12. - match:
  13. - uri:
  14. prefix: /headers
  15. - uri:
  16. prefix: /status
  17. route:
  18. - destination:
  19. port:
  20. number: 8000
  21. host: httpbin
  22. EOF

Output-producing adapters

在此任务中,我们使用名为 keyval 的策略适配器。除输出策略检查结果之外,此适配器还返回一个包含 value 字段的输出。适配器上配置有一个查找表,用于填充输出值,或者在查找表中不存在输入实例键时返回 NOT_FOUND 错误状态。

  • 部署演示适配器:
  1. $ kubectl run keyval --image=gcr.io/istio-testing/keyval:release-1.1 --namespace istio-system --port 9070 --expose
  • 通过模板和配置描述启用 keyval 适配器:

ZipZip

  1. $ kubectl apply -f @samples/httpbin/policy/keyval-template.yaml@
  2. $ kubectl apply -f @samples/httpbin/policy/keyval.yaml@
  • 使用固定的查找表为演示适配器创建一个 Handler:
  1. $ kubectl apply -f - <<EOF
  2. apiVersion: config.istio.io/v1alpha2
  3. kind: handler
  4. metadata:
  5. name: keyval
  6. namespace: istio-system
  7. spec:
  8. adapter: keyval
  9. connection:
  10. address: keyval:9070
  11. params:
  12. table:
  13. jason: admin
  14. EOF
  • 使用 user 请求头作为查找键,为 Handler 创建一个 Instance:
  1. $ kubectl apply -f - <<EOF
  2. apiVersion: config.istio.io/v1alpha2
  3. kind: instance
  4. metadata:
  5. name: keyval
  6. namespace: istio-system
  7. spec:
  8. template: keyval
  9. params:
  10. key: request.headers["user"] | ""
  11. EOF

请求头操作

  • 确保 httpbin 服务可以通过 ingress gateway 正常访问:
  1. $ curl http://$INGRESS_HOST:$INGRESS_PORT/headers
  2. {
  3. "headers": {
  4. "Accept": "*/*",
  5. "Content-Length": "0",
  6. ...
  7. "X-Envoy-Internal": "true"
  8. }
  9. }

输出应该是 httpbin 服务接收到的请求头。

  • 为演示适配器创建 Rule:
  1. $ kubectl apply -f - <<EOF
  2. apiVersion: config.istio.io/v1alpha2
  3. kind: rule
  4. metadata:
  5. name: keyval
  6. namespace: istio-system
  7. spec:
  8. actions:
  9. - handler: keyval.istio-system
  10. instances: [ keyval ]
  11. name: x
  12. requestHeaderOperations:
  13. - name: user-group
  14. values: [ x.output.value ]
  15. EOF
  • 向入口网关发出新请求,将请求 key 设置为值 jason
  1. $ curl -Huser:jason http://$INGRESS_HOST:$INGRESS_PORT/headers
  2. {
  3. "headers": {
  4. "Accept": "*/*",
  5. "Content-Length": "0",
  6. "User": "jason",
  7. "User-Agent": "curl/7.58.0",
  8. "User-Group": "admin",
  9. ...
  10. "X-Envoy-Internal": "true"
  11. }
  12. }

请注意 user-group 标头,该标头派生自适配器的 Rlue 定义,Rlue 中表达式 x.output.value 的取值结果为适配器 keyval 返回值的 value 字段。

  • 如果匹配成功,则修改 Rule 规则,重写 URI 路径到其他 Virtual service 路由:
  1. $ kubectl apply -f - <<EOF
  2. apiVersion: config.istio.io/v1alpha2
  3. kind: rule
  4. metadata:
  5. name: keyval
  6. namespace: istio-system
  7. spec:
  8. match: source.labels["istio"] == "ingressgateway"
  9. actions:
  10. - handler: keyval.istio-system
  11. instances: [ keyval ]
  12. requestHeaderOperations:
  13. - name: :path
  14. values: [ '"/status/418"' ]
  15. EOF
  • 再次向 ingress gateway 发送请求:
  1. $ curl -Huser:jason -I http://$INGRESS_HOST:$INGRESS_PORT/headers
  2. HTTP/1.1 418 Unknown
  3. server: istio-envoy
  4. ...

请注意,在策略适配器的规则应用 之后,ingress gateway 更改了路由。修改后的请求可能使用不同的路由和目的地,并受流量管理配置的约束。

同一代理内的策略引擎不会再次检查已修改的请求。因此,我们建议在网关中使用此功能,以便服务器端策略检查生效。

清理

删除演示适配器的策略资源:

  1. $ kubectl delete rule/keyval handler/keyval instance/keyval adapter/keyval template/keyval -n istio-system
  2. $ kubectl delete service keyval -n istio-system
  3. $ kubectl delete deployment keyval -n istio-system

完成 ingress 任务中的清理说明。

相关内容

APP 身份和访问适配器

使用 Istio 实现零代码改动保护多云 Kubernetes 应用。

Mixer 和 SPOF 神话

提高可用,降低延迟。

Mixer 适配器模型

概要说明 Mixer 的插件架构。

Denials 和黑白名单

描述如何使用简单的 denials 或黑白名单来控制对服务的访问。

Mixer 配置模型

描述 Istio 策略执行和遥测机制的配置模型。

TLS Egress 监控和策略配置

描述如何在 TLS Egress 上配置 SNI 监控和策略。