Feature Overview

This feature extends the platform-wide initiative to ensure comprehensive confidence in certificate management within the Bare Metal Operator (BMO) and Ironic components. By automating the lifecycle of certificates used for bare metal provisioning (including Ironic internals and webhook certificates), this enhancement eliminates manual tracking and ensures compliance with strict security policies. It enforces a default validity period of 2 years or less, supports customizable cryptographic keys (RSA 4096), and provides administrative visibility into rotation schedules.

Goals

• Primary User: Cluster Administrator / Security Compliance Officer.
• Goal: To have "set and forget" confidence that all Bare Metal provisioning certificates are automatically rotated without service disruption and meet rigorous compliance standards (e.g., Telco, Finance).
• Extension: This extends existing BMO functionality by aligning to the new platform-wide certificate standards defined in OCPSTRAT-2568.

Requirements

Functional Requirements

• Comprehensive Certificate Audit: The engineering team must execute the analysis logic (referencing the[ Certificate Analyzer Script|https://github.com/racedo/openshift-certificate-analyzer/tree/main/Bash%20Script]) to identify all certificates owned by cluster-baremetal-operator and metal3.
• Configurable Validity Periods: All identified BMO certificates must default to a validity period of 2 years or less to meet customer security policies.
• Automatic Rotation: Certificates must rotate automatically with sufficient lead time before expiration to ensure zero downtime in production environments.
• Manual Rotation Support: Administrators must have the capability to manually trigger the rotation of long-lived certificates via supported APIs or CLI commands.
• Cryptographic Agility: The operator must support customizable RSA key sizes, specifically allowing upgrades to 4096-bit keys for root CAs as required by compliance standards (aligning with OCPSTRAT-2271).
• Visibility & Reporting: Users must be able to query the rotation status, expiration dates, and renewal schedules for BMO certificates via standard platform APIs or CLI.

Non-Functional Requirements (NFRs)

• Service Continuity: Certificate rotation (automatic or manual) must be tested to ensure it does not disrupt active bare metal provisioning jobs (e.g., hosts currently booting via vMedia or performing introspection).
• External CA Integration: The architecture must evaluate and support paths for integrating External Certificate Authorities for regulated environments (e.g., Telco CMPv2), aligning with OCPSTRAT-2029.
• Observability: The Provisioning Custom Resource (CR) status or associated Operator conditions should reflect certificate health and upcoming rotations.

Use Case

Scenario 1: Regulated Environment Compliance

"As a Security Administrator in a Telecommunications company, I want to configure the Bare Metal Operator to use 4096-bit RSA keys and enforce a 1-year certificate validity period so that I can pass my annual security audit (e.g., ANSSI, EU Cybersecurity Act) without manual intervention."

Scenario 2: Zero-Touch Rotation

"As a Platform Engineer, I want the Ironic TLS and vMedia certificates to rotate automatically 30 days before expiration so that my bare metal clusters do not experience provisioning outages due to expired credentials."

Questions to Answer (Refinement)

• Certificate Scope: Based on the execution of the Certificate Analyzer Script, what is the definitive list of Secrets/ConfigMaps that BMO manages which require migration to this new logic?
• Provisioning Impact: Does the restart of Ironic pods during certificate rotation cause failures for hosts in the middle of the provisioning or inspecting state? Do we need to implement a "drain" logic or specific retry mechanism in the Ironic agent?
• Configuration Interface: Will BMO expose specific fields in the Provisioning CR for key size/validity, or will it strictly watch the global Infrastucture or APIServer configuration resources?

Out of Scope

• Certificates managed by the underlying operating system (CoreOS) or standard Kubernetes API server certificates (unless explicitly managed by BMO).
• Lifecycle management of certificates for components not listed in the ownership.md under Bare Metal Operator.

Links

• Master Outcome: OCPSTRAT-2568: Enhanced Platform Certificate Lifecycle Management and Compliance
• Certificate Registry:[ OpenShift TLS Ownership Registry|https://github.com/openshift/origin/blob/main/tls/ownership/ownership.md#bare-metal-hardware-provisioning--cluster-baremetal-operator-1] 
• Related Feature (Key Sizes): OCPSTRAT-2271
• Related Feature (External CA): OCPSTRAT-2029