Stay organized with collections
Save and categorize content based on your preferences.
Knative serving relies on
Istio for ingress.
Therefore, you are able to
customize and
configure Istio to support your needs. This also means that
Knative serving can be affected by known issues or vulnerabilities
in Istio.
This page was created to help ensure that you configure Knative serving
using known best practices, and that you address any known issues to avoid
unintentionally exposing your resources to vulnerabilities.
For example, given a service at yourservice.com/admin, for which you
configured access to allow requests to the path /admin. If you do not
explicitly deny access to //admin, the path vulnerability in
AuthorizationPolicy fails to prevent access for requests that use the
malformed //admin path. Because your service might not differentiate between
those paths, the request to a malformed path is allowed unintended access.
Background:
The default Istio ingress gateway that is used by Knative serving relies
on default URL pattern normalization, using the
normalize_path
option on Envoy proxies, which follows
RFC 3986.
Unfortunately, there are several known request URL patterns that are not
normalized through the default URL pattern normalization standards. See the
following section about how you can mitigate the vulnerability.
Mitigation:
To help ensure that you are not vulnerable to path confusion attacks today,
there are two possible methods that you can implement:
Recommended option: Deny all access by default
Configure Istio to use a default-deny pattern for AuthorizationPolicy
policies. Generally, this improves your cluster's security posture.
Configuring a default-deny authorization pattern denies all requests to your
services by default and allows you to explicitly define all the conditions
for which a request is allowed access.
Using this pattern might mean that if you fail to allow a specific condition,
certain requests will be unexpectedly denied. This might result in poor
user experience, service outage, or failure to meet your SLO or SLA.
The tradeoff for explicitly defining all access is usually preferred over a
security incident due to unintended access.
Example:
Create a AuthorizationPolicy to use the default-deny pattern by defining
a allow-nothing policy in your target namespace. For example, to
denys all traffic to all services in the default namespace, you create:
Alternative option: Explicitly deny all problematic URL variations to your
service
To avoid implementing a default-deny pattern, you must ensure that your
backend service is able to deny any problematic paths. Depending on your
language, framework, and other factors in how you implement your service, you
must explicitly deny all URL paths that the Istio ingress gateway does not
normalize, including:
Multiple forward slashes or backslashes: //, \\
Escaped sequences of forward slashes or backslashes:
%2F, %2f, %5C, %5c
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[[["\u003cp\u003eKnative Serving uses Istio for ingress, allowing customization but also inheriting any Istio vulnerabilities.\u003c/p\u003e\n"],["\u003cp\u003eThis guide helps configure Knative Serving with best practices and addresses known issues to prevent security vulnerabilities.\u003c/p\u003e\n"],["\u003cp\u003eA vulnerability, CVE-2021-31920, exists in Istio's AuthorizationPolicies when configuring path-based access control, potentially leading to path confusion attacks.\u003c/p\u003e\n"],["\u003cp\u003eThe recommended mitigation is to configure Istio with a default-deny pattern for AuthorizationPolicies, enhancing overall security.\u003c/p\u003e\n"],["\u003cp\u003eAlternatively, you can explicitly deny all problematic URL variations, such as multiple or escaped slashes, in your service to mitigate the path confusion vulnerability.\u003c/p\u003e\n"]]],[],null,["# Security best practices in Knative serving\n\nKnative serving relies on\n[Istio for ingress](/anthos/run/archive/docs/architecture-overview#components_in_the_default_installation).\nTherefore, you are able to\n[customize](/anthos/run/archive/docs/setup#using_a_separate_istio_installation) and\nconfigure Istio to support your needs. This also means that\nKnative serving can be affected by known issues or vulnerabilities\nin Istio.\n\nThis page was created to help ensure that you configure Knative serving\nusing known best practices, and that you address any known issues to avoid\nunintentionally exposing your resources to vulnerabilities.\n\nOther best practices guides and resources:\n\n- [Google Cloud security best practices](/security/best-practices)\n- [GKE Enterprise security tutorial](/anthos/docs/tutorials/security)\n- [Istio security best practices](https://istio.io/latest/docs/ops/best-practices/security/)\n\nKnown vulnerabilities\n---------------------\n\n### Configuring paths in `AuthorizationPolicies`\n\n**Security vulnerability**:\n\n- [CVE-2021-31920](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31920)\n\n**Description**:\n\nYou can use Istio's\n[AuthorizationPolicies](https://istio.io/latest/docs/reference/config/security/authorization-policy/)\nfor access control using the paths to your Knative serving services.\nDue to\n[CVE-2021-31920](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31920),\nif you\n[configure path-based access control](https://istio.io/latest/docs/concepts/security/#value-matching)\nyou might be vulnerable to path confusion attacks.\n\nFor example, given a service at `yourservice.com/admin`, for which you\nconfigured access to allow requests to the path `/admin`. If you do not\nexplicitly deny access to `//admin`, the path vulnerability in\n`AuthorizationPolicy` fails to prevent access for requests that use the\nmalformed `//admin` path. Because your service might not differentiate between\nthose paths, the request to a malformed path is allowed unintended access.\n\n**Background**:\n\nThe default Istio ingress gateway that is used by Knative serving relies\non default URL pattern normalization, using the\n[`normalize_path`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path)\noption on Envoy proxies, which follows\n[RFC 3986](https://tools.ietf.org/html/rfc3986).\n\nUnfortunately, there are several known request URL patterns that are not\nnormalized through the default URL pattern normalization standards. See the\nfollowing section about how you can mitigate the vulnerability.\n\n**Mitigation**:\n\nTo help ensure that you are not vulnerable to path confusion attacks today,\nthere are two possible methods that you can implement:\n\n- **Recommended option: Deny all access by default**\n\n Configure Istio to use a default-deny pattern for `AuthorizationPolicy`\n policies. Generally, this improves your cluster's security posture.\n Configuring a default-deny authorization pattern denies all requests to your\n services by default and allows you to explicitly define all the conditions\n for which a request is allowed access.\n\n Using this pattern might mean that if you fail to allow a specific condition,\n certain requests will be unexpectedly denied. This might result in poor\n user experience, service outage, or failure to meet your SLO or SLA.\n The tradeoff for explicitly defining all access is usually preferred over a\n security incident due to unintended access.\n\n Example:\n\n Create a `AuthorizationPolicy` to use the default-deny pattern by defining\n a `allow-nothing` policy in your target namespace. For example, to\n denys all traffic to all services in the `default` namespace, you create: \n\n apiVersion: security.istio.io/v1beta1\n kind: AuthorizationPolicy\n metadata:\n name: allow-nothing\n namespace: default\n spec:\n {}\n\n To learn more about defining a `AuthorizationPolicy` type policy, see\n [Istio authorization for HTTP traffic](https://istio.io/latest/docs/tasks/security/authorization/authz-http/).\n- **Alternative option: Explicitly deny all problematic URL variations to your\n service**\n\n To avoid implementing a default-deny pattern, you must ensure that your\n backend service is able to deny any problematic paths. Depending on your\n language, framework, and other factors in how you implement your service, you\n must explicitly deny all URL paths that the Istio ingress gateway does not\n normalize, including:\n - Multiple forward slashes or backslashes: `//`, `\\\\`\n - Escaped sequences of forward slashes or backslashes: `%2F`, `%2f`, `%5C`, `%5c`"]]