-
Notifications
You must be signed in to change notification settings - Fork 487
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
GEP: Client Certificate Validation for TLS terminating at the Gateway Listener #2080
GEP: Client Certificate Validation for TLS terminating at the Gateway Listener #2080
Conversation
… Listener Signed-off-by: Arko Dasgupta <[email protected]>
will continue adding more content in the GEP once Ive received broad consensus on the goals & non goals |
(Gateway Listener in this case) during a [TLS Handshake Protocol][], also commonly referred to as mutual TLS (mTLS). | ||
|
||
## Goals | ||
- Define an API field to specify the CA Certificate within the Gateway Listener configuration that can be used as a trusted anchor to validate the certificates presented by the client. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the existing certificateRefs
field where the CA certificate would be specified? Is the idea that this GEP will add a field that can be used to specify something like a client validation cacert key in a cacertificateRefs
secret, for example? Maybe adding an API section with a proposal would be helpful to start the discussion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fwiw, this goal of adding a way to config mTLS termination in a Gateway is valuable and very contained scope IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree that feels like the inevitable placement here. Let's get this in and then we can work on the implementation details.
Thanks @arkodg! Will give @shaneutt and @youngnick a bit more time to review this one, but don't think there's anything controversial here. /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: arkodg, robscott The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@robscott @shaneutt @youngnick Hey guys, since this is no more than a simple (I believe agreed to) problem statement that has been stagnant for a couple of months, can we either get this merged now or otherwise update it with an API proposal so we can start discussing the solution? @argkodg do you have an API for this that you are waiting to propose? |
yah @frankbu, I have an API in mind, that I plan on adding as a follow up PR |
Thanks for the ping on this one @frankbu! I don't think there's anything controversial in the GEP at this point. I've already approved, would like @shaneutt or @youngnick to sign off on this though. /release-note-none |
Yeah, this is pretty tightly scoped as written, so I'm supportive. /lgtm |
/kind gep
Fixes #91