GEP-4078: Certificate Pinning for Client Certificate Validation #4079
Conversation
k8s-ci-robot
added
release-note-none
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
do-not-merge/hold
Signed-off-by: Norwin Schnyder <norwin.schnyder+github@gmail.com>
|
/assign |
geps/gep-91/metadata.yaml
Outdated
| # obsoletes indicates that a GEP makes the linked GEP obsolete, and completely | ||
| # replaces that GEP. The obsoleted GEP MUST have its obsoletedBy field | ||
| # set back to this GEP, and MUST be moved to Declined. | ||
| obsoletes: {} |
There was a problem hiding this comment.
fun fact, this is an array per GEP API definition, and setting it as "{}" will break people trying to programatically unmarshal/decode this (see me fighting and failing against it at #4075
So the right thing here is to set these fields as [] (empty array) and not as {} (empty object).
Take a look into my PR above, you will see me changing this on a lot of places :)
geps/gep-4078/index.md
Outdated
| [RFC8174]: https://www.rfc-editor.org/rfc/rfc8174 | ||
|
|
||
| ## What | ||
| Enhance the existing Client Certificate Validation defined in [GEP-91](../gep-91/index.md) by introducing support for certificate pinning. This allows specifying one or more certificate or public key hashes (SPKI) that are considered valid for client connections. During TLS client authentication, the Gateway will validate not only against the configured CAs, but also against the pinned certificates or keys. This provides a mechanism to restrict allowed clients to a narrowly defined set of certificates, even if the CA trust domain is broad. |
There was a problem hiding this comment.
not really important at this moment, but do we/should we care also about validating the certificate CN or some other field? see as a reference: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#client-certificate-authentication
There was a problem hiding this comment.
IMO CN and SAN validation for client certificates should be part of the Gateway API too, but I would prefer a dedicated GEP for it.
There was a problem hiding this comment.
During TLS client authentication, the Gateway will validate not only against the configured CAs, but also against the pinned certificates or keys.
I think that we should allow configuring validation either with CAs or by certificate pinning. Combining two of them with AND does not make sense to me.
There was a problem hiding this comment.
I updated the GEP to make it clearer that certificate pinning is intended as an alternative to the existing CA-based validation of client certificates.
Signed-off-by: Norwin Schnyder <norwin.schnyder+github@gmail.com>
Signed-off-by: Norwin Schnyder <norwin.schnyder+github@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: snorwin The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind gep
What this PR does / why we need it:
What/Why/Who for enhancing Client Certificate Validation with Certificate Pinning.
Which issue(s) this PR fixes:
Fixes #4078
Does this PR introduce a user-facing change?: