Story (Required)

To support OpenShift’s Post-Quantum Cryptography (PQC) readiness initiative, the webhook must stop managing TLS configuration locally and instead inherit TLS settings from centrally managed OpenShift security configuration.

The webhook currently relies on a locally managed TLS configuration, which creates a security risk and prevents global enforcement of PQC-resilient TLS settings (TLS 1.3+, approved cipher suites).

This story requires refactoring the webhook so that:

1. Webhook certificates are provisioned using the OpenShift Service CA, not self-generated.

1. Webhook TLS configuration (TLS version + ciphers) is dynamically inherited from the API Server TLS Profile, ensuring consistency with OpenShift platform-wide PQC profiles.

1. The webhook aligns with OpenShift’s requirement that components derive TLS settings from one of the global configuration knobs (API Server, Kubelet, or Ingress). For webhooks, the authoritative source is the APIServer TLS Profile.

Technical guide and Examples:https://docs.google.com/document/d/1cMc9E8psHfnoK06ntR8kHSWB8d3rMtmldhnmM4nImjs/edit?tab=t.4cxmujrb3zyn#heading=h.kah5ngeaf35x

Goals

• Remove hardcoded or locally managed TLS.

• Ensure webhook TLS is centrally controlled and PQC-ready.

Acceptance Criteria

Certificate Management

• The webhook’s TLS certificate must be issued by the OpenShift service-ca.

• The webhook Service contains the annotation:
  service.alpha.openshift.io/serving-cert-secret-name: <secret-name>
• The generated secret is mounted into the webhook pod.

• The webhook server loads the certificate/key directly from the mounted Service CA secret.

TLS Configuration Inheritance

• The webhook must not define its own TLS version or cipher suite configuration.

• The webhook must retrieve the effective APIServer TLS Profile 

• The webhook server must apply the TLS profile settings (TLS version, cipher suites) to its server configuration.

• TLS 1.3+ must be supported to enable PQC-resilient algorithms when made available by OpenShift.

Verification Steps

• • OpenShift Pipelines are deployed to the PEnshift cluster.

• • Common tests are validated to ensure they continue to function as expected, including unchanged webhook admission behavior.

• • The Modern TLS profile is validated by updating the API server configuration and observing system behavior after the change.

• • Network-level verification is performed using HPCASE’s tls-scanner to determine which TLS profile settings are accepted over the network (refer to Using tls-scanner for detailed instructions).

Expected Results

• • Only TLS settings permitted by the selected profile are accepted.

• • Each component reflects and adheres to the configured TLS profile.

Reference

• • https://docs.google.com/document/d/1cMc9E8psHfnoK06ntR8kHSWB8d3rMtmldhnmM4nImjs/edit?tab=t.mk0m0or6ab7g#heading=h.s2ar9mmswwua

Known Blocker / Technical Note

Knative TLS injection limitation

Knative’s webhook framework (knative/pkg) currently does not expose a way to inject a full tls.Config:
https://github.com/knative/pkg/blob/main/webhook/webhook.go#L141

This means:

• The team must investigate whether Knative can be extended/wrapped

• OR upstream changes may be needed

• OR a custom serving layer must be introduced around Knative’s webhook