Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow external authorization for non-tls virtual hosts #6657

Open
kncesarini opened this issue Sep 2, 2024 · 3 comments
Open

Allow external authorization for non-tls virtual hosts #6657

kncesarini opened this issue Sep 2, 2024 · 3 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/needs-triage Indicates that an issue needs to be triaged by a project contributor. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@kncesarini
Copy link

Currently, external authorization (via httpproxy) is only possible when using TLS, and even more restrictive than that it is only possible when clients send SNI headers, as using a fallback certificate is also not allowed. I understand there are technical reasons for this from reading the design doc (https://github.com/projectcontour/contour/blob/main/design/external-authorization-design.md), but strongly hope this is something that can be added to the roadmap as it is a blocker for many common architectures.

For us specifically this causes an issue when we use contour together with an AWS ALB. Our original hope was to do TLS offloading on the ALB and then forward http to contour (running in k8s). We figured that we can take the additional step and encrypt traffic between the ALB and contour as well to allow external authorization, but then discovered that the ALB doesn't forward SNI headers, which means it will only ever be able to hit a fallback certificate in envoy, which as said don't allow external auth servers. ALB is unfortunately a non-negotiable necessary component for us and surely many others, primarily as a place to plug in a WAF and public certificates, so just going with an NLB instead for example loses important functionality.

Because of this we're forced to go with a different ingress controller (unless there's some magic solution we're overlooking) solely so that we can have a functional external auth, which is very unfortunate as we really like how it has been implemented in contour apart from this snag.

@kncesarini kncesarini added kind/feature Categorizes issue or PR as related to a new feature. lifecycle/needs-triage Indicates that an issue needs to be triaged by a project contributor. labels Sep 2, 2024
Copy link

github-actions bot commented Sep 2, 2024

Hey @kncesarini! Thanks for opening your first issue. We appreciate your contribution and welcome you to our community! We are glad to have you here and to have your input on Contour. You can also join us on our mailing list and in our channel in the Kubernetes Slack Workspace

@kristiankco
Copy link

I discovered that this already seems to be a thing with the globalExtAuth configuration-
https://github.com/projectcontour/contour/blob/main/design/global-external-authorization-design.md

What still still seems to be missing (?) is being able to toggle this off for specific vhosts or routes as I don't see the configs suggested in the design present in the HTTPProxy CRD. This is of course an issue as not all requests necessarily require authentication, but there's already another issue on this topic so this one can be closed. Pleas also add globalExtAuth to the docs!

Copy link

github-actions bot commented Nov 3, 2024

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

  • After 60d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

  • Mark this Issue as fresh by commenting
  • Close this Issue
  • Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/needs-triage Indicates that an issue needs to be triaged by a project contributor. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Development

No branches or pull requests

2 participants