Control Headers and Routing (Deprecated)
The mixer policy is deprecated in Istio 1.5 and not recommended for production usage.
Consider using Envoy ext_authz
filter, lua
filter, or write a filter using the Envoy-wasm
sandbox.
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 the Installation guide.
Policy enforcement must be enabled in your cluster for this task. Follow the steps in Enabling 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 service configuration for the
httpbin
service containing two route rules that allow traffic for paths/headers
and/status
:$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin
spec:
hosts:
- "*"
gateways:
- httpbin-gateway
http:
- match:
- uri:
prefix: /headers
- uri:
prefix: /status
route:
- destination:
port:
number: 8000
host: httpbin
EOF
Output-producing adapters
In this task, we are using a sample policy adapter keyval
. In addition to a policy check result, this adapter returns an output with a single field called value
. The adapter is configured with a lookup table, which it uses to populate the output value, or return NOT_FOUND
error status if the input instance key is not present in the lookup table.
Deploy the demo adapter:
$ 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:$ kubectl apply -f @samples/httpbin/policy/keyval-template.yaml@
$ kubectl apply -f @samples/httpbin/policy/keyval.yaml@
Create a handler for the demo adapter with a fixed lookup table:
$ kubectl apply -f - <<EOF
apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
name: keyval
namespace: istio-system
spec:
adapter: keyval
connection:
address: keyval:9070
params:
table:
jason: admin
EOF
Create an instance for the handler with the
user
request header as a lookup key:$ kubectl apply -f - <<EOF
apiVersion: config.istio.io/v1alpha2
kind: instance
metadata:
name: keyval
namespace: istio-system
spec:
template: keyval
params:
key: request.headers["user"] | ""
EOF
Request header operations
Ensure the httpbin service is accessible through the ingress gateway:
$ curl http://$INGRESS_HOST:$INGRESS_PORT/headers
{
"headers": {
"Accept": "*/*",
"Content-Length": "0",
...
"X-Envoy-Internal": "true"
}
}
The output should be the request headers as they are received by the httpbin service.
Create a rule for the demo adapter:
$ kubectl apply -f - <<EOF
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
name: keyval
namespace: istio-system
spec:
actions:
- handler: keyval.istio-system
instances: [ keyval ]
name: x
requestHeaderOperations:
- name: user-group
values: [ x.output.value ]
EOF
Issue a new request to the ingress gateway with the header
key
set to valuejason
:$ curl -Huser:jason http://$INGRESS_HOST:$INGRESS_PORT/headers
{
"headers": {
"Accept": "*/*",
"Content-Length": "0",
"User": "jason",
"User-Agent": "curl/7.58.0",
"User-Group": "admin",
...
"X-Envoy-Internal": "true"
}
}
Note the presence of the
user-group
header with the value derived from the rule application of the adapter. The expressionx.output.value
in the rule evaluates to the populatedvalue
field returned by thekeyval
adapter.Modify the rule to rewrite the URI path to a different virtual service route if the check succeeds:
$ kubectl apply -f - <<EOF
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
name: keyval
namespace: istio-system
spec:
match: source.labels["istio"] == "ingressgateway"
actions:
- handler: keyval.istio-system
instances: [ keyval ]
requestHeaderOperations:
- name: :path
values: [ '"/status/418"' ]
EOF
Repeat the request to the ingress gateway:
$ curl -Huser:jason -I http://$INGRESS_HOST:$INGRESS_PORT/headers
HTTP/1.1 418 Unknown
server: istio-envoy
...
Note that the ingress gateway changed the route after the rule application of the policy adapter. The modified request may use a different route and destination and is subject to the traffic management configuration.
The modified request is not checked again by the policy engine within the same proxy. Therefore, we recommend to use this feature in gateways, so that the server-side policy checks take effect.
Cleanup
Delete the policy resources for the demo adapter:
$ kubectl delete rule/keyval handler/keyval instance/keyval adapter/keyval template/keyval -n istio-system
$ kubectl delete service keyval -n istio-system
$ kubectl delete deployment keyval -n istio-system
Complete the clean-up instructions in ingress task.
See also
App Identity and Access Adapter
Using Istio to secure multi-cloud Kubernetes applications with zero code changes.
Improving availability and reducing latency.
Provides an overview of Mixer’s plug-in architecture.
Denials and White/Black Listing (Deprecated)
Shows how to control access to a service using simple denials or white/black listing.
Enabling Policy Enforcement (Deprecated)
This task shows you how to enable Istio policy enforcement.
Enabling Rate Limits (Deprecated)
This task shows you how to use Istio to dynamically limit the traffic to a service.