gep: refine CACertificateRefs description for frontend TLS #4183
Conversation
Signed-off-by: Norwin Schnyder <[email protected]>
k8s-ci-robot
added
release-note-none
|
[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 |
k8s-ci-robot
added
do-not-merge/hold
|
/retest |
| // | ||
| // * It refers to a resource that cannot be resolved (e.g., the | ||
| // referenced resource does not exist) or is misconfigured (e.g., a | ||
| // ConfigMap does not contain a key named `ca.crt`). In this case, the |
There was a problem hiding this comment.
In the improvement proposal for the backend TLS configuration #4123 you included a section about further validation of the referenced certificate, that should be implementation specific:
// Implementations MAY choose to perform further validation of the certificate
// content (e.g., checking expiry or enforcing specific formats). In such cases,
// an implementation-specific Reason and Message MUST be set.
Should we include a similar section for the CA certificate content (e.g., non-empty, at least one valid PEM-encoded TLS CA certificate bundle, ...)? or should this validation be required?
There was a problem hiding this comment.
there is an implementation specific behaviour that ConfigMap can contains 'More than one certificate in a ConfigMap with different keys or more than one reference, or other kinds of resources'. Can you include that?
| This condition remains set to `True` even if `FrontendValidationModeType` is later changed back to `AllowValidOnly`. | ||
|
|
||
| * Introduce a `ObjectReference` structure that can be used to specify `caCertificateRefs` references. | ||
| * Invalid `caCertificateRefs` directly affect the `ResolvedRefs` and `Accepted` conditions of the targeted listeners. |
There was a problem hiding this comment.
Should we also discuss and specify how the Accepted and Programmed Condition of the Gateway are affected
Accepted:
- if at least one listener is valid
- all listeners are invalid
- ...
Programmed:
- e.g. no Listeners can be programmed due to validation issues (e.g., Mode =
AllowValidOnlyeverywhere and all CA certificates are invalid). - ...
There was a problem hiding this comment.
The semantics describing how invalid listeners affect gateway's Accepted condition with the reason ListenersNotValid (https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1/gateway_types.go#L1203) are already defined. Therefore, I omitted the indirect influence on the Gateway status here.
The Programmed condition may be affected if the data plane rejects the configuration, e.g., due to an invalid CA certificate. However, such behavior depends on implementation-specific validations performed by the data plane.
There was a problem hiding this comment.
Is there a listener name or direct reference in this condition?
|
|
||
| * Introduce a `ObjectReference` structure that can be used to specify `caCertificateRefs` references. | ||
| * Invalid `caCertificateRefs` directly affect the `ResolvedRefs` and `Accepted` conditions of the targeted listeners. | ||
| A listener is considered targeted if and only if it is serving HTTPS and either its port matches the port of the |
There was a problem hiding this comment.
Can you split this entry to default and per port? There are 2 distinct fields and it will be easier to explain which Listeners are impacted
| This condition remains set to `True` even if `FrontendValidationModeType` is later changed back to `AllowValidOnly`. | ||
|
|
||
| * Introduce a `ObjectReference` structure that can be used to specify `caCertificateRefs` references. | ||
| * Invalid `caCertificateRefs` directly affect the `ResolvedRefs` and `Accepted` conditions of the targeted listeners. |
There was a problem hiding this comment.
Is there a listener name or direct reference in this condition?
| // | ||
| // * It refers to a resource that cannot be resolved (e.g., the | ||
| // referenced resource does not exist) or is misconfigured (e.g., a | ||
| // ConfigMap does not contain a key named `ca.crt`). In this case, the |
There was a problem hiding this comment.
there is an implementation specific behaviour that ConfigMap can contains 'More than one certificate in a ConfigMap with different keys or more than one reference, or other kinds of resources'. Can you include that?
4 participants
What type of PR is this?
/kind gep
What this PR does / why we need it:
In the current version of GEP-91, the semantics of an invalid
CACertificateRefsare not fully specified. In addition, it is unclear whether theInsecureFrontendValidationModecondition should ever be removed or set to False.This PR clarifies the expected behavior by aligning the semantics of invalid references in frontend validation with the patterns already established in BackendTLSPolicy and the approach proposed in #4123 for backend TLS configuration on the Gateway.
Which issue(s) this PR fixes:
N/A
Does this PR introduce a user-facing change?: