Add ingress-nginx migration docs #1035
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| Currently, TLS connections terminate at the ingress-nginx controller, but client | ||
| certificate validation happens later at the `spaces-router` component. The | ||
| controller extracts the certificate and forwards it in the `ssl-client-cert` | ||
| HTTP header. This presents a security flaw as the TLS handshake and certificate | ||
| validation are separate. | ||
|
|
||
| With TLS passthrough mode, the encrypted connection goes directly to the | ||
| `spaces-router` component. Both the TLS handshake and certificate validation | ||
| happen together and eliminates the security vulnerability. |
There was a problem hiding this comment.
For the sake of correctness, TLS connections are no longer terminated at the ingress (it was previously so). Currently, you need to configure the ingress-nginx controller in the SSL passthrough mode as follows:
- You need to pass the
--enable-ssl-passthrough=truecommand-line option when starting the controller. This enables the SSL-passthrough support at the controller. - And you need to set the
nginx.ingress.kubernetes.io/ssl-passthrough: "true"annotation on theIngressresource to have it pass the SSL traffic upstream without being terminated at the ingress.
So from an SSL-termination point of view, there's no security improvement if a customer switches from the Ingress API to the Gateway API. We had better not list this as a motivation here in my opinion (it might be confusing). This security issue associated with terminating TLS connections at the ingress has already been addressed (even if you are still using the Ingress API).
There was a problem hiding this comment.
For further details, you may also look at this PR description: https://github.com/upbound/spaces/pull/2068. If the customer provisions the Ingress resource themselves, then they need to also include the SSL-passthrough annotation mentioned above. The Spaces Helm chart has been updated with that PR so that if the Ingress resource is being installed as part of the Spaces Helm release, it's already taken care of.
There was a problem hiding this comment.
Removed that section.
|
FYI we wrote up a project around how to handle this in Spaces - https://linear.app/upbound/project/migrate-away-from-ingress-nginx-in-spaces-4f46a7c99c3f/overview I'd like us to understand our options a bit more, specifically around what we are suggesting for the Gateway API implementation i.e. envoy gateway. |
docs/manuals/spaces/howtos/self-hosted/ingress-nginx-migration.md
Outdated
Show resolved
Hide resolved
Signed-off-by: rae sharp <8883519+tr0njavolta@users.noreply.github.com>
Description
Updates docs for ingress-nginx to Envoy for Spaces. https://docs.google.com/document/d/1ZfE7kZTAmKKjHkt6dFNRzki9S6wRnpHbzXa86LVcDw0/edit?tab=t.0#heading=h.valiw6ek06tp
Type of change
Checklist
make lintlocally (or will fix Vale suggestions in review)Additional notes