Add enhancement spec for centralized TLS configuration and enforcement

[richardsonnick]

Centralized and Enforced TLS Configuration Enhancement

This enhancement proposes a mechanism to ensure all OpenShift components honor the centralized TLS security profile configuration, addressing a gap in TLS policy enforcement across the platform.

Summary

Currently, many OpenShift components hardcode TLS settings or rely on library defaults rather than respecting cluster-wide TLS configuration. This creates security vulnerabilities and blocks Post-Quantum Cryptography (PQC) readiness.

This proposal introduces a tlsAdherence field that allows gradual adoption of strict TLS enforcement, providing a safe upgrade path for customers.

Key Features

• Safe upgrade path: New tlsAdherence field with Legacy (default) and Strict modes
• Backwards compatible: Defaults to existing behavior, requires explicit opt-in
• Comprehensive: Applies to core platform components and layered products
• Feature gated: Controlled by TLSAdherenceStrict feature gate during transition

Why This Matters

• Enables consistent cryptographic policy enforcement across all components
• Unblocks PQC readiness initiatives
• Allows customers to enforce custom TLS profiles for compliance requirements
• Prevents components from ignoring configured cipher/TLS version restrictions

Related Work

• Complements the api-tls-curves-config enhancement
• See also kube-apiserver TLS config

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[joelanford]

There were some questions raised in our sync that I think we will need to write down and think about:

1. Should we focus ingress-related improvements in the Gateway API/implementation?
2. What does the ingress configuration apply to? Just the reverse proxies that are in the ingress controllers/routers/gateway implementations? Or are exposed backend services expected to honor the ingress config over the "in-cluster" config? What if the backend service is exposed outside the cluster, but is also expected to be used within the cluster? And lastly, should there be any consideration for the possibility of TLS passthrough (or not) being used for the ingress/route/gateway?

[simonpasquier]

Can we get more details on how one should pick this flavor + some concrete examples?
Case in point: monitoring deploys the node-exporter to all (Linux) nodes via a DaemonSet to collect node metrics. Right now we rely on the API server configuration settings to configure TLS, should we rather switch to Kubelet settings?

Corollary question: what's the use case for different API and kubelet TLS settings?

[joelanford]

@simonpasquier did you ever manage to figure this out? In your case, I think it makes sense to follow apiservers since monitoring isn't directly aligned with the kubelet component itself.

[simonpasquier]

From what I can tell, the proposal focuses on TLS server configuration. I assume that TLS client configuration is out of scope. Asking the question because Prometheus scrapes metrics from operators/operands via HTTPS. Is it ok to consider that the scraped endpoints apply the centralized TLS configuration and we don't need to enforce anything at the client (Prometheus) level?

We also a few components which users can configure to talk to external systems:

• Prometheus can send metrics via remote-write to HTTPS servers.
• Alertmanager can send notifications to HTTPS based API services (as well as emails via STARTTLS).
  Again is it safe to assume that the users are responsible to properly configure these interfaces?

[joelanford]

Right now, the focus is on servers, yes. If we find clients that we ship are using old or constrained TLS implementations that don't offer to negotiate using TLS 1.3 + ML-KEM, then we will likely ask for those clients to be updated because the end result of that client/server combo will not be TLS 1.3 + ML-KEM.

[richardsonnick]

Updated this with a revised draft with up to date information from internal discussions.

[simonpasquier]

who's going to update this condition?

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign tkashem for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[richardsonnick]

Reworked this EP. Removed the proposal of a new CRD for centralizing TLS configuration. The new plan is to use the existing apiserver config for all components. This reduces the complexity of adding a new CRD.

[richardsonnick]

Open question for discussion: What should components do if they are unable to comply with the tls settings? Is there a pattern for bubbling up configuration errors? Should the use the degraded flag?

[rhmdnd]

From the user's perspective, if I set this, where do I go next to find out which components are falling back to legacy behavior?

[everettraven]

To make sure I'm recalling correctly, this mode being configured means "do what you've always done" and is meant to mitigate breaking changes from automatically migrating clusters from "some components respect this API for TLS configuration" to "all components respect this API for TLS configuration".

Should the guidance here instead be something along the lines of:

• IF tlsAdherence: Legacy
  • IF ${component} already respects TLS profile configuration, continue to do so.
  • ELSE do what ${component} has always done, which is presumably that they have not respected the TLS profile and therefore should not

[rhmdnd]

How should a component let the user know it's not going to use the cluster default set in the API server configuration?

[rhmdnd]

Just to make sure my understanding is correct - the best a cluster administrator could do if we land this enhancement without #1894 (assuming we implement consistent enforcement) would be to configure the cluster to use the Modern profile and hope clients prefer the hybrid curves (assuming the cluster admin is prioritizing defense against harvest now, decrypt later attacks).

If we land this enhancement along with #1894 - then they at least have the option force clients to use PQC-safe curves with:

apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  tlsSecurityProfile:
    type: Custom
    custom:
      # ciphers:
      #   - TLS_AES_128_GCM_SHA256  # This will be IGNORED - TLS 1.3 ciphers are hardcoded
      minTLSVersion: VersionTLS13
      curves:
      - X25519MLKEM512
  tlsAdherence: strict

But that requires 1894 to turn off the classical curves.

[simonpasquier]

reposting my comment from #1910 (comment)

I'm assuming that the proposal applies to the server part of managed components and we don't need to enforce any client TLS settings.

[richardsonnick]

reposting my comment from #1910 (comment)
I'm assuming that the proposal applies to the server part of managed components and we don't need to enforce any client TLS settings.
@simonpasquier Yes that is correct

[simonpasquier]

@richardsonnick can this be written down in the proposal? Maybe in the non-goals section?

[simonpasquier]

what about components which already honor the cluster-wide TLS profile? I assume that they should behave the same. E.g. the Cluster monitoring operator already does for a couple of releases now.

[richardsonnick]

My understanding is that, yes they should retain the same behavior.
Looping in @joelanford to confirm

[jcantrill]

The CLO also honor's cluster-wide TLS profile which means on upgade we could potentially revert its behavior since its not one of these Legacy components. How should layered products treat this going forward? What is their expected behavior?

[joelanford]

Legacy means components should retain their existing behavior. The intent is to avoid changes to the server configuration on cluster upgrade. So if components already honor the profile, they should continue honoring the profile.

@richardsonnick we should probably call that out in the EP.

[joelanford]

But that nuance means the name of this enum is not quite true.

@everettraven thoughts on naming for the Legacy* enum?

[joelanford]

I also saw that changes to the TLSSecurityProfile resulted in changes to the Machine Config Operator (I think that was the one). We should call out all of the ones we know about.

And we also may want to audit the rest of the openshift github org (via github search) to see if we can find APIs outside of openshift/api that embed this type. Out-of-tree API definitions may pick this validation change up in the future (when they bump their openshift/api dep)

[richardsonnick]

Created APIs Referencing TLSSecurityProfile section that contains (a hopefully exhaustive) list of references and embeddings of the TLSSecurityProfile type

[joelanford]

api-approvers should be @everettraven

[joelanford]

Seems like:

• oc is related to kubelet, which is go-based and would need the ratcheted validation. I'm guessing this plumbs through to the kubelet config that is in-tree?
• cluster-logging-operator appears to be configuration for a client TLS config, not a server, but we should get confirmation (ping @jcantrill)
• lightspeed-operator is unrelated to anything else, so we definitely need to make them aware and get their feedback.

[jcantrill]

cluster-logging-operator appears to be configuration for a client TLS config, not a server, but we should get confirmation (ping @jcantrill)

The 'server' config of ClusterLogForwarder only relies upon the global cluster setting and does not expose the capability for an admin to overwrite the global settings via CLF. Correctly, the output side of CLF does allow admin to vary from the cluster setting as is necessary to forward logs to the receivers which are under their config control

[joelanford]

Interestingly, I found this code, which already validates cipher suites are not configurable with TLS 1.3: https://github.com/openshift/kubernetes/blob/9d521311f5fb67dc43f49eeb728ee2c80976835a/openshift-kube-apiserver/admission/customresourcevalidation/apiserver/validate_apiserver.go#L214-L219

When does that code run?

[everettraven]

Looks like it should run at admission time of an APIServer config resource :) - might mean you don't need to make any validation updates to the APIServer type, but it might makes sense to move towards using CEL validations for this.

I suspect this validation logic was added as part of our patched-in admission plugin because there was no way to do this evaluation on the CRD at the time.

[joelanford]

I also see:

• Plumbing for microshift ingress that likely needs to change to the new ingress type: https://github.com/openshift/microshift/blob/bda126f67a2cdf076f2b608ee9c9c9dec9b2dda2/pkg/config/ingress.go#L140-L151
• Plumbing for hypershift's hosted apiserver, where we do want to propagate our ratcheting validation

[nrfox]

Layered products should only inherit the cluster default if tlsAdherence=StrictAllComponents, correct? If tlsAdherence=LegacyExternalAPIServerComponentsOnly then layered products should ignore tlsSecurityProfile?

[richardsonnick]

• If tlsAdherence == StrictAllComponents, then layered products should inherit the cluster default.
• If tlsAdherence == LegacyExternalAPIServerComponentsOnlythen layered products should continue doing what they were before. If that means ignoring the TLS security profile then they should continue this behavior.

[simonpasquier]

I don't understand what's the expectation for component owners here. From what I understand, the ordering doesn't matter anymore.

[richardsonnick]

Updated the spec to be more specific here. Component owners should just apply the set of curves in the order given by the CRD regardless of go crypto/tls behavior. Cluster admins will need to be aware of this behavior when we update the documentation to add the new curves field.

[simonpasquier]

thanks, it's clear for me now!

[openshift-ci]

@richardsonnick: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.