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 as default (from APIServer.spec.tlsSecurityProfile)
• Expose a standardized CRD interface (Instaslice.spec.tlsSecurityProfile) to override TLS settings
• 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-284 mandates this for all layered products

Scenarios

1. Default behavior: DAS 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 without operator restart via APIServer watching

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
• Controller watches Pods: The InstasliceReconciler watches v1.Pod resources (not Instaslice CRs) via For(&v1.Pod{}) pattern
• Uncached client for initial fetch: Manager cache is not ready before mgr.Start(), so uncached client is needed to fetch APIServer at startup
• Daemonset webhook unused: Daemonset creates webhook server object but registers no handlers - only controller has /mutate-v1-pod webhook

Acceptance Criteria

• [ ] Operator reads TLS profile from APIServer.spec.tlsSecurityProfile singleton
• [ ] Operator supports CRD override via Instaslice.spec.tlsSecurityProfile
• [ ] TLS resolution order: CRD override > Cluster setting > Intermediate default
• [ ] All HTTPS endpoints (webhooks, metrics) use configured TLS settings
• [ ] Dynamic updates via APIServer watching (no restart required)
• [ ] CSV includes features.operators.openshift.io/tls-profiles: "true" annotation
• [ ] RBAC includes permission to get/list/watch config.openshift.io/apiservers
• [ ] 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-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

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)

• Dynamic reload? YES - Watch APIServer and reconcile on changes, no restart needed
• CRD override? YES - Add spec.tlsSecurityProfile to Instaslice CRD per OCPSTRAT-284
• Metrics authentication? Uses built-in controller-runtime metricsfilters.WithAuthenticationAndAuthorization (no kube-rbac-proxy)

Implementation Approach

Pattern: MCO-style with APIServer watching + CRD override

TLS Profile Resolution Order:

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

Components to Configure:

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

Files to Modify:

• go.mod - Add openshift/api, library-go, client-go
• api/v1alpha1/instaslice_types.go - Add TLSSecurityProfile field
• config/rbac/role.yaml - Add RBAC for apiservers
• internal/controller/tls/ (new) - TLS helper package
• internal/controller/instaslice_controller.go - APIServer watch (currently watches Pods via For(&v1.Pod{}))
• cmd/controller/main.go - Initial TLS config using uncached client
• cmd/daemonset/main.go - Initial TLS config using uncached client
• bundle/manifests/*.clusterserviceversion.yaml - CSV annotation

Done Checklist

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