Ext-authz service is called for every request, while it could be disabled per route (public/private ksvc)

[norbjd]

Context

When ext-authz is enabled, every request to the gateway's external listeners is forwarded to the ext-authz service, because the filter is added to every external listener's HTTPConnectionManager.

My use-case

In my case, I have two kinds of Knative services I want to serve, "public" and "private" ones:

• "public" services (with a visibility: public label) can be called by anyone who knows the URL
• "private" services (with a visibility: private label) can only be called by authenticated users (with a token)

Today, to achieve the authentication mechanism, I'm using the ext-authz configuration provided by Kourier (by setting KOURIER_EXTAUTHZ_HOST). In a nutshell, my ext-authz service is following this logic (pseudo-code):

if serviceHasVisibilityPublicLabel(ksvc) {
  return 200 // call is always authorized
} else if serviceHasVisibilityPrivateLabel(ksvc, request) {
  token := getTokenFromRequest(request)
  if isValidToken(token) {
    return 200 // call is authorized
  } else {
    return 403 // call is unauthorized
  }
}

Problem

As you can see, since ext-authz is enabled globally, all requests to "public" services are also calling my ext-authz service. Even if validating a request to "public" services is a no-op (always return 200), this is still causing congestion on the ext-authz service, while actually, it's not necessary.

Proposed solution

To avoid unnecessary calls to the ext-authz service, I propose to configure ExtAuthzPerRoute filter at every route level, based on the related ksvc labels or annotations. This filter is already used in some internal routes (status or ACME challenge) to disable ext-authz, but it's not generalized to public routes.

When "visibility" label is not provided, the default should be to not add nor configure the ExtAuthzPerRoute filter, so we don't introduce any breaking change. In fact, ExtAuthzPerRoute filter should only be configured (disabled: true) when "visibility" label is set to "public", so ext-authz service can be bypassed (as it will always return 200 anyway).

Some questions

• is enabling ext-authz using labels/annotations at the knative service level a good solution? If so, how should we call this label (visibility works in my case, but we might want something more generic, with knative.dev prefix)
• how does other ingresses (Istio) handle this case? Does this mechanism exist somewhere else?

---

Finally, if you're interested, I'll be happy to help for the implementation.

Thanks!

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[norbjd]

Hello 👋 @skonto @ReToCode do you have any opinion on this 🙏? As you are also working on Knative serving itself, I think you might have an idea if this is something we could implement on kourier, or at a more high level. Thanks!