Mutual authentication between gateway and backend

[jimmyjones2]

What would you like to be added:

In some modes, such as client certificate validation by the gateway (GEP-91), or Gateway/HTTPRoute level authentication (GEP-1494), the backend service would benefit from a cryptographic method of validating the assertions made by the gateway through trusted headers - for example the identity of the authenticated user.

This method could be a projected Kubernetes service account sent by the gateway in an additional HTTP header, or using a mTLS certificate (added manually, or more simply using the upcoming pod certificates upstream feature which could be sent automatically for backends that advertise support).

Why this is needed:

Currently backend services have to be carefully protected by layer 3 NetworkPolicy to ensure only the gateway can initiate connections to the backend and assert the trusted headers. If another pod is able to send traffic to the backend pod, due to a misconfigured or missing NetworkPolicy, it can assert the trusted headers and potentially result in some kind of compromise (e.g. if it can freely assert the identity of any user). For example, allow-same-namespace NetworkPolicy is commonly used in OpenShift, which would allow pods in the same namespace to call the backend.

[rikatz]

https://gateway-api.sigs.k8s.io/geps/gep-3155/

Is this GEP related? If so it is already being implemented #3155

[jimmyjones2]

It is related to GEP-3155 (sorry I should have linked), but auto mTLS is out of scope of that GEP. The issue doesn't have to be solved with mTLS, but I think it's probably the best way.

I guess this issue is twofold:

• Is it worth documenting the reason why mTLS is so important to a backend (have slightly updated the above as it's important for the security of GEP-91 too), or is this commonly understood?
• Now we (nearly) have pod certificates in upstream Kubernetes, is it worth bringing at least the simpler cases of auto mTLS in scope?