Implementation Guide

TLS Security Profile Implementation Guide for Kueue Operator

{warning}Release Blocker: TLS profile compliance is a release blocker as of OCP 4.22 GA. All OpenShift components must support centralized TLS profile configuration by this release.{warning}

Epic Goal

Implement configurable TLS security profiles for the Kueue Operator to:

• Use the cluster's TLS security profile configuration as default (from APIServer.spec.tlsSecurityProfile)
• Expose a standardized CRD interface (Kueue.spec.tlsSecurityProfile) to override TLS settings
• Advertise TLS profile support via CSV annotation for OperatorHub discoverability
• Upstream First: Contribute TLS profile support to upstream Kueue project before implementing in the operator

Post-Quantum Cryptography (PQC) Readiness

This platform-wide TLS profile consistency is a stepping stone in OpenShift's post-quantum cryptographic support journey:

• PQC-resilient algorithms will be available in TLS 1.3 only
• Components must dynamically inherit TLS settings from the designated global configuration source (API Server by default)
• Customers can opt into PQC-resilient ciphers across the entire platform by adjusting the three documented configuration knobs
• Customers in FSI and government sectors require custom TLS profiles that must be enforced platform-wide

Goal: Set up a PQC-ready TLS profile in one pass by properly adhering to all aspects of the configured profile.

Why is this important?

• OpenShift supports cluster-wide TLS configuration for security compliance, but this currently doesn't extend to OLM-managed operators like Kueue
• Customers require consistent cipher selection across all OpenShift components for regulatory compliance
• Kueue Operator is part of the OpenShift value-add and should follow platform security standards
• OCPSTRAT-284 mandates this for all layered products

Scenarios

1. Default behavior: Kueue Operator reads cluster TLS profile from APIServer.spec.tlsSecurityProfile and applies it to all HTTPS endpoints
2. Intermediate profile (default): When no profile is configured, use Intermediate (TLS 1.2, 11 ciphers)
3. Old profile: Support legacy clients with TLS 1.0 and 29 ciphers when cluster admin configures Old profile
4. Modern profile: Maximum security with TLS 1.3 only (3 ciphers) when configured - PQC-ready
5. Custom profile: Support user-defined TLS version and cipher suites
6. Dynamic update: TLS profile changes take effect via rolling restart of operand pods

Architecture Notes

• Two-level operator: Kueue Operator manages the Kueue operand (upstream Kueue controller-manager)
• Upstream dependency: Upstream Kueue currently has no TLS profile configuration - requires KEP and implementation
• TLSOpts pattern: Controller-runtime's metricsserver.Options.TLSOpts and webhook.Options.TLSOpts accept []func(*tls.Config) for TLS customization
• Three HTTPS endpoints: Metrics server (port 8443), Webhook server (port 9443), Visibility API server (port 8082)
• ConfigMap-based config: Operator generates controller_manager_config.yaml ConfigMap with TLS settings for operand

Acceptance Criteria

• [ ] All local or hardcoded TLS configurations removed
• [ ] Component fetches TLS policy from APIServer
• [ ] TLS scanner confirms compliance with global policy
• [ ] Service remains stable after changes
• [ ] Component explicitly respects all TLS profile settings (not Go defaults)
• [ ] Functional testing confirms only permitted TLS settings accepted
• [ ] Component is PQC-ready through proper TLS profile adherence
• [ ] CSV includes features.operators.openshift.io/tls-profiles: "true" annotation
• [ ] RBAC includes permission to get/list/watch config.openshift.io/apiservers (already in place)

Child Stories

Upstream Kueue Contribution

Kueue Operator (Downstream)

Documentation & Validation

Dependencies

• OCPSTRAT-284 - Parent strategy for TLS security profiles
• OCPSTRAT-2553 - Initiative for OLM content TLS compliance
• github.com/openshift/api - TLS profile types (configv1.TLSSecurityProfile, configv1.TLSProfiles)
• github.com/openshift/library-go - Cipher conversion (crypto.OpenSSLToIANACipherSuites)
• github.com/openshift/client-go - OpenShift API client
• kubernetes-sigs/kueue - Upstream Kueue (requires TLS profile contribution)

Implementation Approach

Pattern: Upstream-first with operator integration

TLS Profile Resolution Order:

1. Kueue.spec.tlsSecurityProfile (operator override)
2. APIServer.spec.tlsSecurityProfile (cluster-wide)
3. Intermediate profile (default)

Components to Configure (Upstream Kueue):

• Metrics Server (cmd/kueue/main.go) - uses metricsserver.Options.TLSOpts
• Webhook Server (cmd/kueue/main.go) - uses webhook.Options.TLSOpts
• Visibility API Server (pkg/visibility/server.go) - uses genericoptions.SecureServing

Operator Files to Modify:

• pkg/apis/kueueoperator/v1/types.go - Add TLSSecurityProfile field
• pkg/tls/ (new) - TLS helper package
• pkg/operator/starter.go - Add config client and informer
• pkg/operator/target_config_reconciler.go - APIServer watch, ConfigMap generation
• bundle/manifests/*.clusterserviceversion.yaml - CSV annotation

Parallel Work Strategy

Can Start Now (No Upstream Dependency):

• OCPKUEUE-450 - Create upstream KEP
• OCPKUEUE-458 - Add TLS field to operator CRD
• OCPKUEUE-459 - Create TLS helper package
• OCPKUEUE-460 - Add APIServer informer
• OCPKUEUE-463 - Add CSV annotation

Blocked on Upstream:

• OCPKUEUE-461 - ConfigMap generation (needs upstream API shape)
• OCPKUEUE-462 - Rollout logic
• OCPKUEUE-464, 465, 466 - Testing

Getting Help

• Slack: #forum-ocp-tls-strict-obedience - Questions about TLS profile compliance
• Slack: #forum-operator-fw-program - Operator requirements-related topics
• Slack: #kueue - Upstream Kueue community

References

• OCPNODE-3918 - DAS Operator TLS implementation (reference)
• MCO PR #4435 - Primary reference implementation
• DAS Operator Implementation Guide - Step-by-step guide
• OpenShift TLS Security Profiles Documentation
• Upstream Kueue Repository
• TLS Profile Technical Guide - General guidelines and code samples
• TLS Profile FAQ - Frequently asked questions

Future Work

{info}Note: OCPKUEUE-469 is blocked until openshift/api#2583 merges. The upstream KEP (OCPKUEUE-450) includes curve preferences in its design, so only the operator integration is blocked.{info}

Done Checklist

• [ ] Upstream KEP approved
• [ ] Upstream TLS implementation merged
• [ ] Operator code changes complete
• [ ] Unit tests passing
• [ ] E2E tests passing
• [ ] TLS scanner verification complete
• [ ] Documentation updated
• [ ] Security validation complete
• [ ] PR approved and merged