Enabling requests to Knative services when additional authorization policies are enabled

    You must meet the following prerequisites to use Istio AuthorizationPolicy:

    • Istio must be used for your Knative Ingress. See .
    • Istio sidecar injection must be enabled. See the Istio Documentation.

    Because Knative requests are frequently routed through activator, some considerations need to be made when using mutual TLS.

    Generally, mutual TLS can be configured normally as in Istio’s documentation. However, since the activator can be in the request path of Knative services, it must have sidecars injected. The simplest way to do this is to label the namespace:

    If the activator isn’t injected:

      1. $ kubectl exec deployment/httpbin -c httpbin -it -- curl -s http://httpbin.knative.svc.cluster.local/headers
      2. {
      3.   "headers": {
      4.     "Accept": "*/*",
      5.     "Accept-Encoding": "gzip",
      6.     "Forwarded": "for=10.72.0.30;proto=http",
      7.     "K-Proxy-Request": "activator",
      8.     "User-Agent": "curl/7.58.0",
      9.     "X-B3-Parentspanid": "b240bdb1c29ae638",
      10.     "X-B3-Sampled": "0",
      11.     "X-B3-Spanid": "416960c27be6d484",
      13.     "X-Envoy-Attempt-Count": "1",
      14.     "X-Envoy-Internal": "true"
      15.   }
      16. }

    • In STRICT mode, requests will simply be rejected.

    To understand when requests are forwarded through the activator, see the documentation.

    This also means that many Istio AuthorizationPolicies won’t work as expected. For example, if you set up a rule allowing requests from a particular source into a Knative service, you will see requests being rejected if they are forwarded by the activator.

    For example, the following policy allows requests from within pods in the serving-tests namespace to other pods in the serving-tests namespace.

    Requests here will fail when forwarded by the activator, because the Istio proxy at the destination service will see the source namespace of the requests as knative-serving, which is the namespace of the activator.

    1. apiVersion: security.istio.io/v1beta1
    2. kind: AuthorizationPolicy
    3.  name: allow-serving-tests
    4.  namespace: serving-tests
    6.  action: ALLOW
    7.  rules:
    8.  - from:
    9.    - source:
    10.       namespaces: ["serving-tests", "knative-serving"]

    In addition to allowing your application path, you’ll need to configure Istio AuthorizationPolicy to allow health checking and metrics collection to your applications from system pods. You can allow access from system pods by paths.

    Knative system pods access your application using the following paths:

    • /metrics
    • /healthz

    The /metrics path allows the autoscaler pod to collect metrics. The /healthz path allows system pods to probe the service.

    To add the /metrics and /healthz paths to the AuthorizationPolicy:

    1. Create a YAML file for your AuthorizationPolicy using the following example:

      1. kubectl apply -f <filename>.yaml

      Where <filename> is the name of the file you created in the previous step.