GEP: Gateway/HTTPRoute level authentication

[justinsb]

What would you like to be added:

I would like to be able to enforce authentication & (limited) authorization at the Gateway or HTTPRoute level, so that I can safely route traffic to apps.

Why this is needed:

I'd like to be able to launch kubernetes apps, set up an HTTPRoute for them, and enforce at the gateway level that the user must be logged in (with some restrictions, e.g. *@example.com). Apps can still support perform authentication, but simple read-only apps might not need to. Broadly, I'm trying to follow the approach in the BeyondCorp paper. Doing this greatly improves the security surface of the system (at least when there's less concern over attacks from authenticated users).

Possible mechanisms (mostly to clarify the problem):

• The gateway itself could validate the JWT token (note: likely in a cookie!). Istio's implementation can do this, I believe, but AFAICT not easily in a cookie.
• The gateway could call out to a "helper" URL. I think this was proposed in Pluggable access control #114 but that conversation seems to have been closed by the triagebot.

Ideally this would be at the Gateway level, but I can understand that this might need to be duplicated at the HTTPRoute level if it's considered an HTTP concern.

(I'm new to the project, and not really sure whether this is the right place to raise this. It's not clear whether I should instead - somehow - choose an implementation and then pursue it there, and then the gateway API standardizes features once enough implementations have support. If there's a particular implementation that is a better path for me here, please LMK!)

[shaneutt]

Would you please link the paper that you're referring to? Thank you.

[tokers]

A gateway-scoped authentication support makes sense or users have to add authentication for all routes if they want a global api protection.

[justinsb]

@shaneutt BeyondCorp has its own mini-site here https://cloud.google.com/beyondcorp and generally describes an approach where an organization puts services that would otherwise be on a private network / corporate VPN on the public internet, but with a gateway enforcing authentication (and more). I say "and more" because the authentication can include things like machine certificates. All the papers are good, but https://storage.googleapis.com/pub-tools-public-publication-data/pdf/45728.pdf is probably the most directly relevant here.

In general though, I'm just trying to find a mechanism in the API to enforce auth, for example ingres-nginx had auth-url and auth-signin annotations: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/ .

(It is possible I'm just missing it in the API - I'm not sure if you're saying it does exist at the HTTP route level today @tokers ?)

[youngnick]

I think that we've always intended to support some method of configuring auth, but haven't got around to specifying it yet.

But when I look, we've also never logged an issue to track that. Thanks @justinsb, I guess this is now the tracking issue. 😄

This one definitely requires a GEP specifying how it will work.

The strawman idea I've had (once I finish fixing up Policy Attachment to allow it as part of moving it to Standard in #713) is that
Authentication settings should be specified with a HTTPFilter that can be defaulted or overridden using an AuthenticationPolicy. That will allow you to:

• attach the Policy to a Gateway and default auth settings (but still allow them to be overridden by individual HTTPRoutes)
• attach the Policy to a Gateway and override auth settings (which will prevent them being changed on individual HTTPRoutes)
• Not have a Policy at all and just set the settings on individual HTTPRoutes

Which I think should cover most of the use cases I can think of.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[maleck13]

Not sure this is the right issue to add this, happy to be redirected or open something separate if needed. I wanted to chime in on the subject of Auth and policy attachment. Would love to learn more about any potential improvement to policy attachment.

One of the values I see with policy attachment for this kind of thing (auth), is it allows 3rd parties to implement the solution as a policy and provide the underlying integration and wiring with the gateway providers of their choice behind the scenes.
Filters as I understand them would be provider specific?

We have a project that is defining APIs that use some of the concepts in policy attachment https://github.com/Kuadrant/kuadrant-operator AuthPolicy: https://github.com/Kuadrant/kuadrant-operator/blob/main/config/samples/kuadrant_v1beta1_authpolicy.yaml
RateLimitPolicy: https://github.com/Kuadrant/kuadrant-operator/blob/main/config/samples/kuadrant_v1beta1_ratelimitpolicy.yaml
These don't fully implement policy attachment yet. With complex policies we are struggling and wresting with how to implement overrides and defaults but see the power in allowing a GW admin to define a sane default and have that overridden lower down the hierarchy where there is more knowledge.
I hadn't considered an option where a policy would override a filter as you describe it @youngnick would definitely be interested in learning more about that, and whether there has been any consideration given to allowing filters provided by none gateway providers?

To piggy back on this, comment/issue and the area of policy attachment, one additional difficulty we find with policy attachment, especially when targeting a HTTPRoute, is the desire to target a particular path or method with the policy. I would love to know your thoughts on how that should be achieved @youngnick would we expect multiple HTTPRoutes each with their own policy or a policy to define a mechanism to select a sub section of the route?

[youngnick]

In general, I personally have been expecting that it would be Gateway controllers reconciling associated Policy objects that change its own data plane. I hadn't considered the idea of using Policy objects as a coordination point between a data plane and other plugins, but I suppose it could be done. The good part is that the Gateway API shouldn't really care about how the Policy is implemented, just that it is.

Having a Policy influence the configuration of a Filter is part of #1565, I see this as allowing a Gateway owner to do things like say "every HTTPRoute attached to this Gateway gets this custom filter with these settings, that is overridable by the HTTPRoute owner" (for the defaults use case).

For targeting some part of a resource with a Policy, we've already got https://gateway-api.sigs.k8s.io/geps/gep-713/#apply-policies-to-sections-of-a-resource-future-extension, which talks about how we could attach a policy only to some subsection of an object. Obviously, that's still future work, but I think something like that is quite likely, see #1489 for some more discussion (and please feel free to put your comments on there as well).

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[youngnick]

/remove-lifecycle rotten