Implementation Guide

TLS Security Profile Implementation Guide for DAS Operator

Epic Goal

Implement configurable TLS security profiles for the DAS Operator to:

• Use the cluster's TLS security profile configuration (from APIServer.spec.tlsSecurityProfile) via a lister
• Advertise TLS profile support via CSV annotation for OperatorHub discoverability

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 DAS
• Customers require consistent cipher selection across all OpenShift components for regulatory compliance
• DAS Operator is part of the OpenShift value-add and should follow platform security standards
• OCPSTRAT-2611 mandates this for all OpenShift components (core and layered products)

Scenarios

1. Default behavior: DAS Operator reads cluster TLS profile from APIServer.spec.tlsSecurityProfile via lister 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

Architecture Notes

• No kube-rbac-proxy: DAS Operator uses controller-runtime's built-in metricsfilters.WithAuthenticationAndAuthorization for metrics authentication instead of kube-rbac-proxy sidecar
• Lister-based approach: Use a client/lister to fetch APIServer.spec.tlsSecurityProfile at startup
• No CRD field: Per OCPSTRAT-2611, inherit from cluster-wide source rather than managing locally
• Daemonset webhook unused: Daemonset creates webhook server object but registers no handlers - only controller has /mutate-v1-pod webhook

Acceptance Criteria

Core TLS Implementation

• [ ] Operator reads TLS profile from APIServer.spec.tlsSecurityProfile singleton using a lister
• [ ] TLS resolution: Cluster setting > Intermediate default
• [ ] All HTTPS endpoints (webhooks, metrics) use configured TLS settings
• [ ] CSV includes features.operators.openshift.io/tls-profiles: "true" annotation
• [ ] RBAC includes permission to get/list/watch config.openshift.io/apiservers

OCPSTRAT-2611 Compliance

• [ ] No hardcoded TLS: All local or hardcoded TLS configurations removed from codebase
• [ ] Explicit TLS settings: Component explicitly sets all TLS parameters (MinVersion, MaxVersion, CipherSuites) - does NOT rely on Go crypto/tls defaults
• [ ] tls-scanner verification: Security re-scan using tls-scanner confirms endpoints are compliant with configured TLS policy
• [ ] Custom profile testing: Functional testing confirms component accepts only permitted TLS settings (including custom profiles)
• [ ] PQC-ready: Component is set up for PQC readiness by properly adhering to all aspects of the configured TLS profile

Testing

• [ ] Unit tests for TLS profile resolution
• [ ] E2E tests for TLS configuration verification

Future Work

• OCPNODE-3970 - Add TLS curve preferences support when openshift/api#2583 merges. This is tracked as a separate story and is blocked until the upstream PR is merged.

Dependencies

• OCPSTRAT-2611 - Parent initiative for centralized TLS configuration
• 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

Getting Help

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

Previous Work / References

• MCO PR #4435 - Primary reference implementation
• CMO APIServerConfig - Clean wrapper pattern
• cluster-olm-operator TLS observer - library-go ConfigObserver pattern
• OpenShift TLS Security Profiles Documentation

Open Questions (Resolved)

• CRD override? NO - Per OCPSTRAT-2611, components should inherit from cluster-wide source rather than managing locally
• Metrics authentication? Uses built-in controller-runtime metricsfilters.WithAuthenticationAndAuthorization (no kube-rbac-proxy)

Implementation Approach

Pattern: Lister-based with cluster-wide TLS profile inheritance

TLS Profile Resolution Order:

1. APIServer.spec.tlsSecurityProfile (cluster-wide)
2. Intermediate profile (default)

Components to Configure:

• Webhook Server (pkg/operator/operator.go) - registers /mutate-v1-pod webhook
• Metrics Server (pkg/operator/operator.go) - uses metricsfilters.WithAuthenticationAndAuthorization
• Daemonset Metrics Server (pkg/daemonset/daemonset.go) - metrics only, no webhook handlers

Files to Modify:

• pkg/operator/operator.go - Register configv1 scheme, fetch and apply TLS config
• pkg/daemonset/daemonset.go - Register configv1 scheme, fetch and apply TLS config
• pkg/tlsconfig/ (new) - TLS helper package
• deploy/02_operator_rbac.yaml - Add RBAC for apiservers
• bundle-ocp/manifests/das-operator.clusterserviceversion.yaml - RBAC and CSV annotation

Done Checklist

• [ ] Code changes complete
• [ ] Unit tests passing
• [ ] E2E tests passing
• [ ] tls-scanner verification passing
• [ ] Documentation updated
• [ ] PR approved and merged