Authservice should ignore specified paths and not redirect to the IDP for authentication

[cfryanr]

Traffic for configured paths and methods (e.g. GET /health) should be allowed to pass the authservice without being redirected to the IDP. For instance an application's marketing landing page or health endpoint may not require a user be logged in to view it.

Both the Istio authn policy and the authz policies (both the deprecated RBAC authz policy and the new authz policy) already allow excluding paths and methods.

[cfryanr]

It appears that you can configure the ext_authz filter to be skipped based on paths, so maybe the authservice does not need to also this kind of configuration option itself?

https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter#per-route-configuration

[cfryanr]

We tried using Istio's EnvoyFilter to configure the Envoy ext_authz settings for skipping specific paths, but it does not seem possible.

We were allowed to use a MERGE operation with applyTo VIRTUAL_HOST to insert a route into the default virtual host, but it always merges by inserting it at the end of the array, and we need it to be at the start of the array because the default is for path "/" and we want to put more specific paths in the array before that. The docs say that INSERT_BEFORE is not supported with an applyTo HTTP_ROUTE or ROUTE_CONFIGURATION (see https://istio.io/docs/reference/config/networking/envoy-filter/#EnvoyFilter-ApplyTo).

It seems like we do need a feature in the authservice's config to skip auth for certain paths.

Note that the Istio JWT filter has a similar configuration option (see triggerRules on https://istio.io/docs/reference/config/security/istio.authentication.v1alpha1/#Jwt) so there is precedence for having such an option on a filter. That option allows users to use complex AND and OR logic on each request to decide if a JWT should be required based on path. Perhaps the authservice should have a similar configuration option. The Istio JWT filter implements this logic in a helper class.

When the Istio authn policy is applied, Pilot translates it into an envoy filter chain which has an envoy.config.filter.http.jwt_authn.v2alpha.JwtAuthentication envoy filter with allow_missing_or_failed turned on, followed by an Istio istio.envoy.config.filter.http.authn.v2alpha1.FilterConfig which actually does the path checking. The trigger_rules live on the second filter only. If we were to someday enhance the Istio JwtAuthentication policy to allow the authservice to be enabled/configured, then it would need to also give a copy of the trigger_rules to the authservice filter, which would be inserted into the filter chain before both of the others.