• Control Headers and Routing
    • Before you begin
    • Output-producing adapters
    • Request header operations
    • Cleanup
    • 相关内容

    Control Headers and Routing

    This task demonstrates how to use a policy adapter to manipulate request headers and routing.

    Before you begin

    • Set up Istio on Kubernetes by following the instructions in theInstallation guide.

    Policy enforcement must be enabled in your cluster for this task. Follow the steps inEnabling Policy Enforcement to ensure that policy enforcement is enabled.

    • Follow the set-up instructions in the ingress task to configure an ingress using a gateway.

    • Customize the virtual serviceconfiguration for the httpbin service containing two route rules that allow traffic for paths /headers and/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

    In this task, we are using a sample policy adapter keyval. In addition toa policy check result, this adapter returns an output with a single fieldcalled value. The adapter is configured with a lookup table, which it uses topopulate the output value, or return NOT_FOUND error status if the inputinstance key is not present in the lookup table.

    • Deploy the demo adapter:
    1. $ kubectl run keyval --image=gcr.io/istio-testing/keyval:release-1.1 --namespace istio-system --port 9070 --expose
    • Enable the keyval adapter by deploying its template and configuration descriptors:

    ZipZip

    1. $ kubectl apply -f @samples/httpbin/policy/keyval-template.yaml@
    2. $ kubectl apply -f @samples/httpbin/policy/keyval.yaml@
    • Create a handler for the demo adapter with a fixed lookup table:
    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
    • Create an instance for the handler with the user request header as a lookup key:
    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

    Request header operations

    • Ensure the httpbin service is accessible through the 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. }

    The output should be the request headers as they are received by the httpbin service.

    • Create a rule for the demo adapter:
    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
    • Issue a new request to the ingress gateway with the header key set to value 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. }

    Note the presence of the user-group header with the value derived from therule application of the adapter. The expression x.output.value in the ruleevaluates to the populated value field returned by the keyval adapter.

    • Modify the rule to rewrite the URI path to a different virtual service routeif the check succeeds:
    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
    • Repeat the request to the ingress gateway:
    1. $ curl -Huser:jason -I http://$INGRESS_HOST:$INGRESS_PORT/headers
    2. HTTP/1.1 418 Unknown
    3. server: istio-envoy
    4. ...

    Note that the ingress gateway changed the route after the rule applicationof the policy adapter. The modified request may use a different route anddestination and is subject to the traffic management configuration.

    The modified request is not checked again by the policy engine within thesame proxy. Therefore, we recommend to use this feature in gateways, sothat the server-side policy checks take effect.

    Cleanup

    Delete the policy resources for the demo adapter:

    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

    Complete the clean-up instructions in ingress task.

    相关内容

    App Identity and Access Adapter

    Using Istio to secure multi-cloud Kubernetes applications with zero code changes.

    Mixer and the SPOF Myth

    Improving availability and reducing latency.

    Mixer Adapter Model

    Provides an overview of Mixer's plug-in architecture.

    Denials 和黑白名单

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

    Enabling Policy Enforcement

    This task shows you how to enable Istio policy enforcement.

    Mixer Configuration Model

    Describes the configuration model for Istio's policy enforcement and telemetry mechanisms.