Skip to content

GEP: Client Certificate Validation for TLS terminating at the Gateway Listener #2080

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Jul 20, 2023
Merged

GEP: Client Certificate Validation for TLS terminating at the Gateway Listener #2080

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions geps/gep-91.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# GEP-91: Client Certificate Validation for TLS terminating at the Gateway Listener

* Issue: [#91](https://github.com/kubernetes-sigs/gateway-api/issues/91)
* Status: Provisional

(See definitions in [GEP Status][/contributing/gep#status].)

## TLDR

This GEP proposes a way to validate the TLS certificate presented by the downstream client to the server
(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.
Copy link
Contributor

@frankbu frankbu Jun 23, 2023

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?

Copy link
Contributor Author

@arkodg arkodg Jun 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah you're right @frankbu , ive been advised to not define the HOW until the the maintainers have agreed on the goals here, so taking it one step at a time

Copy link
Contributor

@frankbu frankbu Jun 23, 2023

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.

Copy link
Member

@robscott robscott Jun 23, 2023

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.


## Non-Goals
- Define other fields that can be used to verify the client certificate such as the Cerificate Hash or Subject Alt Name.

## References

[TLS Handshake Protocol]: https://www.rfc-editor.org/rfc/rfc5246#section-7.4
[Certificate Path Validation]: https://www.rfc-editor.org/rfc/rfc5280#section-6