Skip to content

Conversation

@sanchezl
Copy link
Contributor

@sanchezl sanchezl commented Nov 20, 2025

Update TLS security profile documentation for clarity and consistency in preparation for possibly updating the pre-defined TLS profiles in an upcoming release.

@openshift-ci-robot
Copy link

Pipeline controller notification
This repository is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Nov 20, 2025

Hello @sanchezl! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

@coderabbitai
Copy link

coderabbitai bot commented Nov 20, 2025

Walkthrough

Added a new public field minTLSVersion to tlsSecurityProfile.custom across many generated CRD/feature-gated manifests (enum: VersionTLS10/11/12/13), updated TLS profile documentation strings in API source, OpenAPI and Swagger outputs to reference Mozilla TLS 5.0 and forward-compatibility, and in some manifests expanded the tlsSecurityProfile.type enum to include Modern.

Changes

Cohort / File(s) Summary
API source comments
config/v1/types_tlssecurityprofile.go
Revised docstrings and inline comments for TLSSecurityProfile, Old/Intermediate/Modern/CustomTLSProfile, related constants and TLSProfileSpec to reference Mozilla TLS 5.0, clarify intent/equivalences and forward-compatibility. No exported type/signature changes.
Generated CRD manifests (config/v1 & payload)
config/v1/zz_generated.crd-manifests/*0000_10_config-operator_01_apiservers-*.crd.yaml, config/v1/zz_generated.crd-manifests/*0000_80_machine-config_01_kubeletconfigs.crd.yaml, payload-manifests/crds/*0000_10_config-operator_01_apiservers-*.crd.yaml, payload-manifests/crds/*0000_80_machine-config_01_kubeletconfigs.crd.yaml
Added minTLSVersion to tlsSecurityProfile.custom (examples and schema text showing enum VersionTLS10/11/12/13), consolidated example placement, and rewrote profile descriptions/examples to show explicit equivalence to Custom with minTLSVersion values; removed legacy notes.
Feature-gated/generated CRD manifests
config/v1/zz_generated.featuregated-crd-manifests/*, machineconfiguration/v1/zz_generated.featuregated-crd-manifests/*, operator/v1/zz_generated.featuregated-crd-manifests/*
Added minTLSVersion to tlsSecurityProfile.custom examples/schemas and updated profile descriptions; ensured minTLSVersion enum values present and updated prose for forward-compatibility.
Operator / Ingress CRDs
operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml, operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml
Introduced minTLSVersion under tlsSecurityProfile.custom examples/schemas and adjusted Intermediate/Modern/Old equivalence text to reference explicit minTLSVersion mappings; documentation changes only.
MachineConfig / KubeletConfigs CRDs
machineconfiguration/v1/zz_generated.crd-manifests/*, machineconfiguration/v1/zz_generated.featuregated-crd-manifests/*, machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml, machineconfiguration/v1/zz_generated.featuregated-crd-manifests/kubeletconfigs.machineconfiguration.openshift.io/AAA_ungated.yaml
Rewrote TLS profile descriptions, added/illustrated minTLSVersion in custom examples, and presented explicit equivalences to Custom profiles with minTLSVersion values.
OpenAPI / Swagger generated docs
openapi/generated_openapi/zz_generated.openapi.go, config/v1/zz_generated.swagger_doc_generated.go, config/v1/zz_generated.swagger_doc_generated.go
Updated OpenAPI/Swagger description strings for TLSSecurityProfile, TLSProfileSpec, and profile-specific entries (Old/Intermediate/Modern/Custom) to guideline-focused wording and removed legacy notes about max allowed TLS version; string changes only.
Feature-gated manifest variants & environment-specific CRDs
*DevPreviewNoUpgrade*.crd.yaml, *TechPreviewNoUpgrade*.crd.yaml, *CustomNoUpgrade*.crd.yaml, feature-gated copies under zz_generated.featuregated-crd-manifests/*, payload-manifests/*
Consistent addition of minTLSVersion examples and documentation rewrites across multiple environment-specific manifest variants; some manifests also expanded tlsSecurityProfile.type enum to include Modern.
Other generated manifests (KMS, AAA_ungated, payloads)
config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml, config/v1/zz_generated.featuregated-crd-manifests/KMSEncryptionProvider.yaml, payload-manifests/crds/*
Added minTLSVersion to tlsSecurityProfile.custom examples and updated profile type descriptions and enums where applicable; documentation and example placement adjusted.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

  • Review focus:
    • Confirm minTLSVersion is present and the enum values (VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13) are consistently defined across all generated CRD manifests and feature-gated variants.
    • Verify any manifests that expanded tlsSecurityProfile.type to include Modern did so consistently and that enum lists match across related manifests.
    • Ensure added minTLSVersion is represented appropriately in CRD schemas (not only examples) where intended and that OpenAPI/Swagger descriptions align with schema changes.
    • Check example YAML snippets for syntactic validity and that duplicate/stray minTLSVersion lines were removed.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.5.0)

Error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented
The command is terminated due to an error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented


Comment @coderabbitai help to get the list of available commands and usage tips.

@openshift-ci openshift-ci bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Nov 20, 2025
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between 0952bf6 and ce5b632.

📒 Files selected for processing (1)
  • config/v1/types_tlssecurityprofile.go (3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**

⚙️ CodeRabbit configuration file

-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.

Files:

  • config/v1/types_tlssecurityprofile.go
🔇 Additional comments (7)
config/v1/types_tlssecurityprofile.go (7)

7-20: ✓ Clear, consistent documentation for Type field.

The expanded comments effectively explain the profile types and their relationship to Mozilla guidelines. The intent-based nature of profiles and potential cipher list reduction are now explicit, which will help users understand forward compatibility considerations.


22-63: ✓ Old profile documentation effectively demonstrates equivalence.

The expanded comment clearly explains the use case and provides a concrete Custom profile equivalent. This will help users understand what they're getting with the Old profile and how to replicate it if needed.


69-89: ✓ Intermediate profile documentation is clear and consistent.

The expanded documentation provides good context about use cases and equivalence to Custom profiles, maintaining consistency with the Old profile documentation style.


91-103: ✓ Modern profile documentation is clear and appropriately concise.

The comment effectively communicates the TLS 1.3 focus and provides the Custom profile equivalent. The reduced verbosity is appropriate given the profile's simplicity.


121-131: ✓ Profile type struct documentation improves discoverability.

Adding documentation comments to OldTLSProfile, IntermediateTLSProfile, and ModernTLSProfile types provides better context for developers exploring the API and improves code documentation generation tools (e.g., godoc).


144-157: ✓ TLSProfileType constant documentation is clear and consistent.

Updated comments consistently reference the Mozilla Server Side TLS guidelines and provide good context for each constant value. This improves maintainability and user understanding.


201-210: ✓ TLSProfiles map documentation is clearer and more actionable.

The updated comments provide explicit Mozilla guidelines reference with version and date, and the NOTE section is reworded for better clarity about validation and whitelisting. This will help operators understand the constraints and appropriate usage patterns.

@sanchezl sanchezl changed the title update TLS security profile documentation for clarity and consistency NO-JIRA: update TLS security profile documentation for clarity and consistency Nov 20, 2025
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Nov 20, 2025
@openshift-ci-robot
Copy link

@sanchezl: This pull request explicitly references no jira issue.

In response to this:

Update TLS security profile documentation for clarity and consistency in preparation for possibly updating the pre-defined TLS profiles in an upcoming release.

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 openshift-eng/jira-lifecycle-plugin repository.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
config/v1/types_tlssecurityprofile.go (1)

201-210: Consider replacing “whitelist” with “allowlist” in NOTE

For more modern and inclusive terminology, you may want to replace “whitelist” with “allowlist” in the NOTE about callers validating constants. For example:

-// of ties, the kube-apiserver wins. Do not fail, just be sure to whitelist only
-// and everything will be ok.
+// of ties, the kube-apiserver wins. Do not fail, just be sure to allowlist only
+// and everything will be ok.

This keeps the meaning while aligning with current wording conventions.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between ce5b632 and be117b4.

📒 Files selected for processing (1)
  • config/v1/types_tlssecurityprofile.go (3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**

⚙️ CodeRabbit configuration file

-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.

Files:

  • config/v1/types_tlssecurityprofile.go
🔇 Additional comments (1)
config/v1/types_tlssecurityprofile.go (1)

7-118: Doc updates for TLS profiles look consistent and accurate

The updated comments for TLSSecurityProfile, the Old/Intermediate/Modern profile fields, and the associated profile types cleanly describe intent, Mozilla TLS 5.0 basis, and the equivalence to the concrete TLSProfiles entries (minTLSVersion and cipher lists) without changing behavior. This improves clarity while keeping the API stable.

Also applies to: 121-158

Copy link
Contributor

@everettraven everettraven left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These docs updates look good to me, but you will need to regenerate the CRDs.

If you run PROTO_OPTIONAL=true make update and include the changes in your commit, that should resolve the verify failure

@openshift-ci openshift-ci bot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Dec 1, 2025
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml (1)

111-247: Clarify KubeletConfig TLS profile docs—Modern profile is currently unsupported

The CRD documentation includes a Modern profile example with minTLSVersion: VersionTLS13, but OpenShift docs confirm that the Modern profile is not currently supported for KubeletConfig. The higher-level note (lines 112–114) correctly states that only Old and Intermediate profiles are supported with a maximum minTLSVersion of VersionTLS12, but the Modern profile section should either be removed from the KubeletConfig CRD or clearly marked as unsupported to avoid user confusion.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between be117b4 and 4479e6d.

📒 Files selected for processing (13)
  • config/v1/types_tlssecurityprofile.go (3 hunks)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (2 hunks)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yaml (2 hunks)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (2 hunks)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (2 hunks)
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml (2 hunks)
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (2 hunks)
  • config/v1/zz_generated.swagger_doc_generated.go (3 hunks)
  • machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml (2 hunks)
  • machineconfiguration/v1/zz_generated.featuregated-crd-manifests/kubeletconfigs.machineconfiguration.openshift.io/AAA_ungated.yaml (2 hunks)
  • openapi/generated_openapi/zz_generated.openapi.go (6 hunks)
  • operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml (2 hunks)
  • operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml (2 hunks)
✅ Files skipped from review due to trivial changes (2)
  • openapi/generated_openapi/zz_generated.openapi.go
  • operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
  • config/v1/types_tlssecurityprofile.go
🧰 Additional context used
📓 Path-based instructions (1)
**

⚙️ CodeRabbit configuration file

-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.

Files:

  • config/v1/zz_generated.swagger_doc_generated.go
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml
  • machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml
  • machineconfiguration/v1/zz_generated.featuregated-crd-manifests/kubeletconfigs.machineconfiguration.openshift.io/AAA_ungated.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml
🔇 Additional comments (12)
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)

296-440: TLS profile documentation for APIServer CustomNoUpgrade is consistent and clear

The updated tlsSecurityProfile docs (custom example with minTLSVersion, expanded Old/Intermediate/Modern descriptions, and the type text referencing Mozilla TLS 5.0 and intent‑based profiles) are internally consistent and align with the shared TLSSecurityProfile contract. No further changes needed here.

config/v1/zz_generated.swagger_doc_generated.go (1)

2946-2986: Swagger TLS profile descriptions align with CRD text and intended semantics

The refreshed Swagger docs for IntermediateTLSProfile, ModernTLSProfile, OldTLSProfile, TLSProfileSpec.minTLSVersion, and TLSSecurityProfile look consistent with the CRD descriptions and with the Mozilla TLS 5.0–based profile intent, including the explicit Custom equivalence examples. No issues from an API or documentation‑consistency perspective.

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)

308-341: TLS profile doc updates look consistent and clear.

minTLSVersion under Custom plus equivalence mappings for Intermediate/Modern/Old read well and match the intent-based guidance. No schema or validation concerns spotted.

Also applies to: 344-365, 369-379, 382-421, 424-439

operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml (1)

1991-2023: Ingress TLS docs: clear equivalence and forward-compat additions.

Custom minTLSVersion and the profile equivalence sections are coherent and consistent with intent-based profiles.

Also applies to: 2026-2049, 2051-2063, 2064-2104, 2106-2122

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)

308-341: DevPreview APIServer TLS documentation improvements look good.

Custom minTLSVersion example and updated profile texts align with the techpreview/default variants.

Also applies to: 344-365, 369-379, 382-421, 424-439

config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml (1)

239-271: Feature‑gated APIServer TLS profile doc refresh LGTM.

Consistent with other CRDs; no validation or enum issues observed.

Also applies to: 275-296, 299-311, 312-351, 355-371

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yaml (1)

239-271: Default APIServer TLS docs: consistent and accurate.

minTLSVersion under Custom and equivalence mappings are clear; schemas and enums remain coherent.

Also applies to: 274-296, 299-311, 312-351, 354-371

machineconfiguration/v1/zz_generated.featuregated-crd-manifests/kubeletconfigs.machineconfiguration.openshift.io/AAA_ungated.yaml (1)

111-116: Do not edit auto-generated CRD manifests directly.

This file is auto-generated (indicated by the zz_generated prefix). The suggested edits will be overwritten on the next code generation cycle. If the documentation about TLS version support is outdated or contradictory, the fix must be applied to the source code or templates that generate this CRD manifest, not to the manifest itself.

Additionally, the claimed contradiction may be version-specific rather than absolute: OpenShift only reliably supported Modern (TLS 1.3) for kubelet starting in the 4.19 release; earlier versions (4.6–4.18) documented Modern as unsupported for kubelet. The presence of Modern/TLS1.3 in the schema does not mean all releases support it for kubelet. To clarify the guidance, update the source generator or template, not this generated file, and include OpenShift version context if needed.

Likely an incorrect or invalid review comment.

config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (4)

343-365: Profile description updates are clear and well-motivated.

The intermediate profile description now properly documents:

  • Forward-compatibility intent with TLS 1.3 ciphers
  • Explicit minTLSVersion equivalence (VersionTLS12)
  • Reference to Mozilla TLS 5.0 guidelines

The minTLSVersion: VersionTLS12 mapping is correct for the intermediate profile level.


368-378: Modern profile introduction is well-specified.

The new modern profile is clearly defined with:

  • TLS 1.3–only support (minTLSVersion: VersionTLS13)
  • Focused cipher suite (only TLS 1.3 ciphers)
  • Appropriate use-case description

381-420: Old profile backward-compatibility intent is explicit.

The old profile description correctly documents:

  • Legacy client support with minTLSVersion: VersionTLS10
  • Inclusion of TLS 1.3 ciphers for forward compatibility
  • Comprehensive cipher list for maximum compatibility

The minTLSVersion mapping is appropriate for legacy support.


328-340: Verify that the minTLSVersion field schema aligns with Go type definitions.

The new minTLSVersion enum field is properly defined with all four TLS versions (1.0–1.3). However, since this is a generated file, confirm that:

  1. The underlying Go type in the API package has been updated with this field
  2. The code generator was re-run to produce this manifest
  3. All related CRD manifests across config/v1/ and operator/v1/ directories include consistent schema changes

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 6

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
machineconfiguration/v1/zz_generated.featuregated-crd-manifests/kubeletconfigs.machineconfiguration.openshift.io/AAA_ungated.yaml (1)

113-155: Update the TLS security profile constraint note to reflect current KubeletConfig support.

Lines 113–115 state "only Old and Intermediate profiles are currently supported, and the maximum available minTLSVersion is VersionTLS12," but this constraint is outdated. Current OpenShift versions support all four profiles (Old, Intermediate, Modern, and Custom) and all four minTLSVersion values (VersionTLS10 through VersionTLS13). The enum at lines 150–154 correctly includes all versions. The constraint note should be updated to accurately describe current support, or clarified to indicate it applies only to specific older OpenShift versions.

♻️ Duplicate comments (8)
payload-manifests/crds/0000_10_config-operator_01_apiservers-Default.crd.yaml (2)

239-239: ****

The minTLSVersion example and enum definition are identical to the TechPreviewNoUpgrade variant and correctly implement the new field.

Also applies to: 259-271


358-360: ****

Same Mozilla TLS v5.0 reference pinning issue as noted in the TechPreviewNoUpgrade manifest. Consider updating both references to reflect current Mozilla guidance or explicitly document the version pinning rationale.

payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)

308-308: ****

Identical minTLSVersion field addition and example across all payload-manifests variants.

Also applies to: 328-340

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yaml (2)

239-239: ****

Identical minTLSVersion implementation across generated CRD manifests; changes are consistent.

Also applies to: 259-271


355-364: ****

Same Mozilla TLS reference issue present in generated manifests. Since these files are auto-generated (zz_generated prefix), verify that the source Go file (config/v1/types_tlssecurityprofile.go) was updated with the corrected Mozilla TLS reference.

#!/bin/bash
# Verify that the source Go file has been updated with TLS profile documentation
# and check Mozilla TLS reference consistency

rg -n -A5 "Mozilla Server Side TLS" config/v1/types_tlssecurityprofile.go
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)

308-308: ****

Identical to other generated CRD manifests; consistent implementation across feature-set variants.

Also applies to: 328-340

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)

308-308: ****

Consistent implementation across all generated CRD variants.

Also applies to: 328-340

machineconfiguration/v1/zz_generated.featuregated-crd-manifests/kubeletconfigs.machineconfiguration.openshift.io/AAA_ungated.yaml (1)

239-248: ****

Same Mozilla TLS v5.0 reference issue. Since this is a generated manifest, verify the source file for consistency.

🧹 Nitpick comments (4)
machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml (1)

122-122: Use a stronger example (avoid TLS 1.1)

The Custom profile example uses minTLSVersion: VersionTLS11. Recommend demonstrating VersionTLS12 to set a safer baseline in docs.

-                        minTLSVersion: VersionTLS11
+                        minTLSVersion: VersionTLS12
@@
-                            minTLSVersion: VersionTLS11
+                            minTLSVersion: VersionTLS12

Also applies to: 148-149

operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml (1)

1997-1999: Strengthen Custom example to TLS 1.2

Use VersionTLS12 instead of VersionTLS11 in the example to avoid suggesting TLS 1.1.

-                        minTLSVersion: VersionTLS11
+                        minTLSVersion: VersionTLS12
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)

308-314: Prefer TLS 1.2 in Custom example

Switch example minTLSVersion to VersionTLS12 to avoid normalizing TLS 1.1 in guidance.

-                        minTLSVersion: VersionTLS11
+                        minTLSVersion: VersionTLS12
config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml (1)

239-245: Update Custom example to TLS 1.2

Use VersionTLS12 to promote stronger defaults in documentation.

-                        minTLSVersion: VersionTLS11
+                        minTLSVersion: VersionTLS12
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between 4479e6d and 37be723.

📒 Files selected for processing (17)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (2 hunks)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yaml (2 hunks)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (2 hunks)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (2 hunks)
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml (2 hunks)
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (2 hunks)
  • config/v1/zz_generated.swagger_doc_generated.go (3 hunks)
  • machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml (2 hunks)
  • machineconfiguration/v1/zz_generated.featuregated-crd-manifests/kubeletconfigs.machineconfiguration.openshift.io/AAA_ungated.yaml (2 hunks)
  • openapi/generated_openapi/zz_generated.openapi.go (6 hunks)
  • operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml (2 hunks)
  • operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml (2 hunks)
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (2 hunks)
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-Default.crd.yaml (2 hunks)
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (2 hunks)
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (2 hunks)
  • payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs.crd.yaml (2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**

⚙️ CodeRabbit configuration file

-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.

Files:

  • payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • config/v1/zz_generated.swagger_doc_generated.go
  • openapi/generated_openapi/zz_generated.openapi.go
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-Default.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • machineconfiguration/v1/zz_generated.featuregated-crd-manifests/kubeletconfigs.machineconfiguration.openshift.io/AAA_ungated.yaml
  • operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yaml
  • operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml
  • payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs.crd.yaml
🧬 Code graph analysis (1)
config/v1/zz_generated.swagger_doc_generated.go (1)
config/v1/types_tlssecurityprofile.go (2)
  • IntermediateTLSProfile (127-127)
  • ModernTLSProfile (131-131)
🔇 Additional comments (16)
payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)

308-308: TLS profile schema and documentation updates look solid.

The addition of minTLSVersion field with clear enum constraints and the updated profile descriptions with explicit Mozilla TLS 5.0 equivalence mappings improve clarity significantly. The examples and forward-compatibility guidance are well-structured.

Also applies to: 328-340, 343-365, 368-379, 381-421, 423-439

payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs.crd.yaml (2)

122-122: Documentation and schema structure are consistent with APIServer CRD.

The TLS profile updates match the pattern in the APIServer CRD: clear examples, enum definitions, equivalence mappings, and Mozilla TLS 5.0 guidance. The schema changes themselves are sound; the issue is the conflicting operational constraints in the description.

Also applies to: 142-154, 157-179, 181-193, 195-235, 237-254


112-114: No action required — the schema design is intentional and the description is accurate.

The minTLSVersion enum includes VersionTLS13 for forward-compatibility and explicitness, but OpenShift currently marks the Modern profile (TLS 1.3) as unsupported for KubeletConfig. The description stating "the maximum available minTLSVersion is VersionTLS12" is correct and accurately reflects the current supported scope. Including VersionTLS13 in the schema while documenting the practical limit to VersionTLS12 is an intentional design pattern to allow future adoption without requiring schema changes. The description and enum are consistent with OpenShift's documented behavior and require no changes.

Likely an incorrect or invalid review comment.

operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml (1)

1974-1983: IngressController TLS profile documentation is clear and forward-looking.

The updates are consistent with the APIServer CRD pattern. The explicit warning in the description (lines 1979–1983) that "the effective profile configuration is subject to change between releases" is valuable, especially for this operator-managed resource. Equivalence mappings and Mozilla TLS 5.0 references are consistent across all three CRDs.

Also applies to: 1991-1991, 2011-2023, 2026-2048, 2051-2062, 2064-2104, 2106-2122

config/v1/zz_generated.swagger_doc_generated.go (5)

2945-2947: Intermediate profile doc is clear and aligned with intent-based Mozilla mapping

The updated summary succinctly ties IntermediateTLSProfile to the intermediate Mozilla TLS configuration, which is sufficient at this level; no issues.


2953-2955: Modern profile doc succinctly captures its Mozilla “modern” basis

The description clearly communicates that ModernTLSProfile tracks the Mozilla modern profile; nothing to change here.


2961-2963: Old profile doc adequately scopes its Mozilla “old” intent

The OldTLSProfile text correctly positions this as the legacy/compat profile; clear and consistent with the other profile summaries.


2969-2973: minTLSVersion description is clearer with an explicit example

The revised TLSProfileSpec.minTLSVersion doc explains behavior in terms of negotiated minimum plus a concrete YAML example, which improves user understanding without changing semantics.


2979-2986: Expanded TLSSecurityProfile docs are consistent and practically useful

The new type, old, intermediate, modern, and custom descriptions:

  • Reference the exact Mozilla TLS 5.0 guideline basis.
  • Spell out equivalence to a Custom profile via minTLSVersion and explicit cipher lists.
  • Emphasize intent-based evolution and the risks of custom.

This gives operators concrete, actionable guidance while remaining forward-compatible; looks good.

openapi/generated_openapi/zz_generated.openapi.go (3)

11851-11851: LGTM: Clear and consistent minTLSVersion documentation.

The simplified description with example improves clarity. Both occurrences use identical text, maintaining consistency across the schema.

Also applies to: 20283-20283


15457-15457: LGTM: Consistent profile type descriptions.

The descriptions clearly reference Mozilla Server Side TLS configuration guidelines with consistent formatting across all three profile types (Old, Intermediate, Modern).

Also applies to: 15924-15924, 17506-17506


20305-20334: LGTM: Comprehensive TLS profile documentation with helpful equivalence mappings.

The documentation improvements are excellent:

  • Clear use-case guidance for each profile level
  • Explicit equivalent Custom profile configurations (Old→TLS10, Intermediate→TLS12, Modern→TLS13)
  • Forward compatibility mentions for TLS 1.3 ciphers
  • Appropriate warning for custom profiles

Note: The documentation references Mozilla guidelines version 5.0 (released 2019-06-28). The PR description indicates awareness of potentially updating profiles in an upcoming release, so this appears intentional for the current documentation baseline.

payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (2)

308-313: Add minTLSVersion example to custom profile documentation.

The minTLSVersion field is now exposed in the Custom TLS profile. Line 308 correctly shows an example with minTLSVersion: VersionTLS11, and the enum is properly defined at lines 335–339 with all four TLS version options (VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13). This change clarifies that operators can explicitly configure minimum TLS versions in custom profiles.

Also applies to: 328-340


344-365: Profile equivalence mappings enhance documentation clarity.

The reworded descriptions for intermediate (lines 344–350), modern (lines 369–371), and old (lines 382–386) profiles now explicitly state their equivalence to Custom profiles with specific minTLSVersion values (VersionTLS12, VersionTLS13, and VersionTLS10, respectively). This forward-compatibility framing and explicit mapping to Custom parameters significantly improves usability and reduces confusion about profile differences.

Also applies to: 369-378, 382-420

config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (2)

308-340: ****

The minTLSVersion field, enum definition, and profile equivalence mappings are correctly implemented across all profile types (custom, intermediate, modern, old) with consistent forward-compatibility language and explicit equivalence statements.

Also applies to: 344-365, 369-378, 382-420


427-429: Mozilla TLS reference still references outdated v5.0 from 2019.

This is a continuation of a prior review concern marked as "✅ Addressed in commit 37be723," but the issue persists. Lines 427–429 still reference "version 5.0 of the Mozilla Server Side TLS configuration guidelines (released 2019-06-28)." Mozilla's current guidance has a build date of 2025-02-24. Either update all affected CRD manifests to the current Mozilla guidance version, or explicitly document the v5.0 pinning with a rationale and pinning date so operators understand this is intentional.

Since these files are auto-generated (zz_generated prefix), the source Go file likely needs updating. Verify whether the source documentation was corrected but regeneration wasn't run, or if the reference update is still pending across the codebase.

Copy link
Contributor

@everettraven everettraven left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside from my one comment on the separation between the list items, this change seems good to me.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (3)
payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs.crd.yaml (1)

111-122: Fix stale note about supported TLS profiles and minTLSVersion

The description still says “only Old and Intermediate profiles are currently supported” and that the maximum available minTLSVersion is VersionTLS12, but this schema and the subfield docs now expose Modern and allow VersionTLS13. Please update or drop that note so it reflects the actual supported enum values and profile mappings.

machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml (1)

111-115: Inconsistent schema: Modern/VersionTLS13 in enum but unsupported for KubeletConfig.

The description correctly states "only Old and Intermediate profiles are currently supported, and the maximum available minTLSVersion is VersionTLS12." However, the schema properties at lines 122–128 likely include Modern and VersionTLS13 as valid enum values. Modern is not supported as a control-plane/kubelet minimum in OpenShift; it is either unavailable or treated as Intermediate. Remove Modern and VersionTLS13 from the allowed enum values in this CRD, or add explicit validation to reject/map them and update the description to explain the fallback behavior.

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)

435-439: Modern enum requires TLS 1.3 but has version-dependent support—document limitations.

The Modern tlsSecurityProfile type requires TLS 1.3 minimum; however, many OpenShift releases do not support TLS 1.3 as the control-plane minimum. Earlier OCP versions either convert Modern to Intermediate silently or mark it as unsupported. While the setting propagates to kube-apiserver, openshift-apiserver, and oauth-apiserver, users selecting Modern should be aware that: (1) support is version-dependent (OCP 4.19+ has full support), (2) unsupported releases may downgrade to Intermediate, and (3) deployment may fail or behave unexpectedly on earlier versions. Consider adding a note in documentation or CRD description clarifying which OCP versions support Modern, or recommend Intermediate (TLS 1.2+1.3) for broader compatibility.

♻️ Duplicate comments (7)
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)

424-433: Update Mozilla TLS guideline reference

Same stale v5.0 link; replace with canonical URL or document rationale for pinning.

Suggested tweak (same as earlier file). See prior comment for diff and verification.

operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml (1)

2113-2122: Replace stale Mozilla v5.0 link with canonical reference

This repeats the previously flagged issue. Use the canonical URL or state pinning rationale.

Minimal change:

- The profiles are currently based on version 5.0 of the Mozilla Server Side TLS
- configuration guidelines (released 2019-06-28) with TLS 1.3 ciphers added for
- forward compatibility. See: https://ssl-config.mozilla.org/guidelines/5.0.json
+ The profiles align with Mozilla's Server Side TLS configuration guidelines,
+ with TLS 1.3 ciphers included for forward compatibility. See:
+ https://ssl-config.mozilla.org/ (canonical).
payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)

424-433: Update stale Mozilla guideline link

Same v5.0 link; replace with canonical URL or document pinning.

config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (1)

424-433: Stale Mozilla v5.0 reference — update or justify pin

This was already flagged; please update to canonical URL or document why v5.0 is intentionally pinned.

Suggested minimal replacement shown in earlier comments.

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)

424-434: Update Mozilla TLS reference to canonical source (duplicate of prior feedback).

Replace fixed v5.0/date with the living guidance URL or add explicit pin rationale; update the generator comments.

Is Mozilla’s “Server Side TLS” guidance maintained as a living doc, and what URL should we cite?
machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml (1)

241-247: Update Mozilla TLS reference (v5.0) to canonical or add pin rationale.

Replace the fixed versioned JSON link/date with the living guidance URL, or document why v5.0 is intentionally pinned; update source comments that generate this CRD.

#!/bin/bash
# Sweep for “only Old and Intermediate” notes to keep messaging consistent
rg -n 'only Old and Intermediate' -C2
config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml (1)

358-364: Refresh Mozilla TLS reference (duplicate of earlier comment).

Prefer the canonical Server Side TLS guidance URL or add an explicit pin rationale to v5.0; fix in the generating source.

Is citing https://mozilla.github.io/server-side-tls/ preferable to versioned JSON for long-lived docs?
🧹 Nitpick comments (16)
payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (2)

336-340: Surface deprecation risk for TLS 1.0/1.1 in API docs

Allowing VersionTLS10/VersionTLS11 is often non-compliant (e.g., PCI DSS) and weak by current standards. Add a brief warning to the minTLSVersion description that TLS 1.0/1.1 are deprecated/insecure and may be blocked in certain modes (e.g., FIPS), so use only as last resort.

Proposed doc tweak:

   minTLSVersion:
     description: |-
       minTLSVersion is used to specify the minimal version of the TLS protocol
       that is negotiated during the TLS handshake. For example, to use TLS
       versions 1.1, 1.2 and 1.3 (yaml):
 
         minTLSVersion: VersionTLS11
+      Note: TLS 1.0 and 1.1 are deprecated and considered insecure by modern
+      guidance (e.g., PCI DSS, industry best practices). Prefer VersionTLS12+
+      and use lower versions only as a last resort. Deployments in certain
+      compliance modes may reject TLS 1.0/1.1.

382-420: “Old” profile caution

Listing an “Old” profile is fine for legacy, but consider adding a one-line caution here that it weakens security posture and should be temporary. Keeps users from unintentionally standardizing on it.

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (2)

336-340: Add deprecation warning for TLS 1.0/1.1

Mirror the warning about deprecated TLS 1.0/1.1 in this TechPreview CRD as well to discourage insecure choices.


382-420: Legacy “Old” profile caution

Consider adding a brief “use only as last resort; degrades security posture” note here too for consistency.

operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml (2)

2018-2029: Warn about TLS 1.0/1.1 here as well

Add a one-line deprecation advisory in minTLSVersion description to discourage insecure configs.


2071-2109: Old profile: add explicit caution

Recommend adding a brief warning that this profile is legacy-only and weakens security.

payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (2)

336-340: Add TLS 1.0/1.1 deprecation notice

Replicate the warning on deprecated protocol versions to steer users to TLS 1.2+.


382-420: Old profile: cautionary note suggested

As above, add brief caution about legacy/weak security posture.

config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (2)

336-340: TLS 1.0/1.1 deprecation advisory

Add one-line advisory on TLS 1.0/1.1 deprecation to the minTLSVersion description here too.


382-420: Old mapping: add explicit caution

Recommend adding a brief caution to avoid normalizing weak settings.

operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml (1)

1991-1997: Use a safer example minTLSVersion (avoid TLS 1.1).

Change the example to VersionTLS12 to avoid encouraging weak protocol versions in user copy/paste.

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)

308-314: Avoid TLS 1.1 in examples.

Recommend VersionTLS12 in the Custom profile example to reflect current security expectations.

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)

308-314: Strengthen example minTLSVersion.

Suggest VersionTLS12 instead of VersionTLS11.

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yaml (1)

239-245: Example should not promote TLS 1.1.

Use VersionTLS12 in the example for better baseline security.

machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml (1)

122-128: Avoid TLS 1.1 in examples.

Prefer VersionTLS12 in the Custom example.

config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml (1)

239-245: Strengthen the example minTLSVersion.

Use VersionTLS12 rather than VersionTLS11.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between 37be723 and 92bb14e.

📒 Files selected for processing (18)
  • config/v1/types_tlssecurityprofile.go (3 hunks)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (2 hunks)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yaml (2 hunks)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (2 hunks)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (2 hunks)
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml (2 hunks)
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (2 hunks)
  • config/v1/zz_generated.swagger_doc_generated.go (3 hunks)
  • machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml (2 hunks)
  • machineconfiguration/v1/zz_generated.featuregated-crd-manifests/kubeletconfigs.machineconfiguration.openshift.io/AAA_ungated.yaml (2 hunks)
  • openapi/generated_openapi/zz_generated.openapi.go (6 hunks)
  • operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml (2 hunks)
  • operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml (2 hunks)
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (2 hunks)
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-Default.crd.yaml (2 hunks)
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (2 hunks)
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (2 hunks)
  • payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs.crd.yaml (2 hunks)
✅ Files skipped from review due to trivial changes (1)
  • machineconfiguration/v1/zz_generated.featuregated-crd-manifests/kubeletconfigs.machineconfiguration.openshift.io/AAA_ungated.yaml
🚧 Files skipped from review as they are similar to previous changes (2)
  • openapi/generated_openapi/zz_generated.openapi.go
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
🧰 Additional context used
📓 Path-based instructions (1)
**

⚙️ CodeRabbit configuration file

-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.

Files:

  • operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml
  • machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml
  • config/v1/zz_generated.swagger_doc_generated.go
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • config/v1/types_tlssecurityprofile.go
  • payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-Default.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
🧬 Code graph analysis (2)
config/v1/zz_generated.swagger_doc_generated.go (1)
config/v1/types_tlssecurityprofile.go (2)
  • IntermediateTLSProfile (127-127)
  • ModernTLSProfile (131-131)
config/v1/types_tlssecurityprofile.go (1)
config/v1/zz_generated.swagger_doc_generated.go (4)
  • OldTLSProfile (2867-2869)
  • IntermediateTLSProfile (2851-2853)
  • ModernTLSProfile (2859-2861)
  • CustomTLSProfile (2843-2845)
🔇 Additional comments (25)
payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs.crd.yaml (1)

156-253: TLS profile equivalence docs look consistent with core TLSProfiles

The new intermediate, modern, and old descriptions that spell out the equivalent Custom profile (including minTLSVersion and cipher lists) align with the Go TLSProfiles map and improve clarity for users composing custom profiles. No further changes needed here.

config/v1/types_tlssecurityprofile.go (1)

3-211: TLS profile comments and mappings are internally consistent

The updated comments for TLSSecurityProfile, Old/Intermediate/ModernTLSProfile, TLSProfileType, and TLSProfiles correctly describe the Mozilla TLS 5.0 basis, intent-based behavior, and the exact Custom-equivalent minTLSVersion/cipher lists that match the TLSProfiles map and TLSProtocolVersion enum. No functional concerns here.

config/v1/zz_generated.swagger_doc_generated.go (1)

2847-2888: Swagger TLS profile docs correctly mirror core type comments

The updated SwaggerDoc entries for Old/Intermediate/ModernTLSProfile, TLSProfileSpec.minTLSVersion, and TLSSecurityProfile match the corresponding Go comments and CRD descriptions, including the Mozilla 5.0 reference and Custom-equivalence examples. This keeps the generated API docs consistent; no changes requested.

payload-manifests/crds/0000_10_config-operator_01_apiservers-Default.crd.yaml (1)

227-371: APIServer TLS profile schema and docs are consistent and clear

The tlsSecurityProfile description, Custom example (including minTLSVersion), and the detailed old/intermediate/modern equivalence text all line up with the Go TLSSecurityProfile/TLSProfiles definitions and the shared CRD/OpenAPI docs. This should make TLS profile behavior much clearer to consumers.

payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (3)

308-314: Good example placement for minTLSVersion

Including minTLSVersion in the Custom example improves clarity and forward-compatibility. No issues.


344-353: Equivalence note is helpful

Stating that Intermediate ≅ Custom with minTLSVersion: VersionTLS12 reduces ambiguity. Looks good.


369-378: Modern profile mapping is clear

Clear guidance that Modern ≅ Custom with TLS 1.3 minimum. LGTM.

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (3)

308-314: Custom example: LGTM

The example with minTLSVersion improves usability.


344-353: Intermediate ≅ Custom(TLS1.2) clarity

Clear, consistent with other CRDs.


369-378: Modern ≅ Custom(TLS1.3) clarity

Consistent and correct.

operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml (3)

1997-2003: Custom example inclusion: OK

minTLSVersion in example improves operator UX.


2033-2054: Intermediate mapping doc: OK

Clear equivalence and cipher ordering.


2058-2067: Modern mapping doc: OK

No issues.

payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (3)

308-314: Custom example: LGTM

Consistent with other manifests.


344-353: Intermediate ≅ Custom(TLS1.2) clarity

Looks good.


369-378: Modern ≅ Custom(TLS1.3) clarity

Looks good.

config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (3)

308-314: Custom example: LGTM

Consistent, helpful example.


344-353: Intermediate mapping clarity

OK.


369-378: Modern mapping clarity

OK.

operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml (1)

2118-2122: Verify Modern TLS profile implementation in operator source code.

This is a generated CRD manifest file; changes here will be overwritten. Confirm that the ingress-controller operator's source implementation properly supports and validates the Modern TLS profile (TLS 1.3 minimum) before relying on this schema addition.

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)

424-434: Update the source generator for this CRD manifest to reference current TLS guidance or document the v5.0 pin.

This file is auto-generated (zz_generated). Rather than modifying it directly, the source that generates this manifest should reference the living Mozilla Server Side TLS page or include a documented reason for the intentional v5.0 (2019-06-28) pin and review cadence for updates. Locate and update the generator source file.

config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml (1)

366-370: Modern in enum: confirm APIServer support and validation.

Please verify controllers accept Modern/TLS1.3 minimum and document any limitations.

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yaml (2)

358-365: Stale Mozilla "v5.0" reference.

The Mozilla Server Side TLS reference is dated 2019-06-28 and should either be updated to current guidance or accompanied by documentation explaining why v5.0 is intentionally pinned. Since the YAML file is auto-generated, the fix must be made in the source Go docstrings.


366-370: Modern TLS profile requires version constraints in schema or documentation.

The Modern option exposes TLS 1.3 as a minimum, but this requires explicit minTLSVersion enforcement and documented minimum cluster/component version requirements. Since this is an auto-generated CRD file, ensure the OpenAPI schema validation or operator documentation (not this manifest) clearly states that Modern profile demands cluster and control-plane support for TLS 1.3.

config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)

435-439: Modern profile in DevPreview: confirm real support and any feature-gate.

Verify that controllers don't reject Modern/TLS1.3 minimum. If this is preview-only functionality, document any limitations in the API description or controller logic.

Comment on lines +2110 to +2116
The profiles are currently based on version 5.0 of the Mozilla Server Side TLS
configuration guidelines (released 2019-06-28) with TLS 1.3 ciphers added for
forward compatibility. See: https://ssl-config.mozilla.org/guidelines/5.0.json
The profiles are intent based, so they may change over time as new ciphers are developed and existing ciphers
are found to be insecure. Depending on precisely which ciphers are available to a process, the list may be
reduced.
Note that the Modern profile is currently not supported because it is not
yet well adopted by common software libraries.
The profiles are intent based, so they may change over time as new ciphers are
developed and existing ciphers are found to be insecure. Depending on
precisely which ciphers are available to a process, the list may be reduced.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

Mozilla Server Side TLS canonical guidance current version 2025

💡 Result:

The canonical Mozilla "Server Side TLS" guidance current version is 5.0. [1][2]

Sources:

  • Mozilla Server Side TLS canonical JSON (server-side-tls-conf.json), version: 5.0. [1]
  • MozillaWiki archive of Server Side TLS (context and historical versions). [2]

🌐 Web query:

mozilla.org ssl-config Server Side TLS guidelines latest

💡 Result:

Here are Mozilla’s Server‑Side TLS (SSL) resources and where to get the latest guidelines:

  • Main Server Side TLS document / site (current source): Mozilla Server Side TLS. [1]
  • SSL Configuration Generator (produces server configs for Modern/Intermediate/Old): ssl-config.mozilla.org / GitHub repo. [2][3]
  • Machine-readable latest guideline (always points to the newest recommendations): https://statics.tls.security.mozilla.org/server-side-tls-conf.json. Use this URL if you need the programmatic/latest JSON. [1]

Sources:
[1] Mozilla — Server Side TLS / static JSON (mozilla.github.io/server-side-tls / statics.tls.security.mozilla.org).
[2] Mozilla SSL Configuration Generator (website/repo).
[3] mozilla/ssl-config-generator — GitHub.


Update Mozilla TLS reference to use canonical programmatic source.

This file is auto-generated (zz_generated); update the source that generates this CRD manifest to reference https://statics.tls.security.mozilla.org/server-side-tls-conf.json instead of the pinned ssl-config.mozilla.org/guidelines/5.0.json. The canonical source always reflects the current guidance and will auto-update when Mozilla releases new versions, whereas the pinned URL risks becoming outdated when v6.0 is released.

🤖 Prompt for AI Agents
In
operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml
around lines 2110-2116, the manifest references the pinned Mozilla TLS JSON
(https://ssl-config.mozilla.org/guidelines/5.0.json); update the generator
input/source that produces this auto-generated CRD manifest to use the canonical
programmatic URL
https://statics.tls.security.mozilla.org/server-side-tls-conf.json instead of
the pinned guidelines URL so the generated comment and any embedded TLS profile
JSON come from the always-current Mozilla canonical endpoint; make this change
in the code/configuration that generates zz_generated files (not by editing the
generated YAML directly) and re-run the generator to regenerate the CRD.

Comment on lines +424 to +433
type is one of Old, Intermediate, Modern or Custom. Custom provides the
ability to specify individual TLS security profile parameters.
The profiles are intent based, so they may change over time as new ciphers are developed and existing ciphers
are found to be insecure. Depending on precisely which ciphers are available to a process, the list may be
reduced.
The profiles are currently based on version 5.0 of the Mozilla Server Side TLS
configuration guidelines (released 2019-06-28) with TLS 1.3 ciphers added for
forward compatibility. See: https://ssl-config.mozilla.org/guidelines/5.0.json
Note that the Modern profile is currently not supported because it is not
yet well adopted by common software libraries.
The profiles are intent based, so they may change over time as new ciphers are
developed and existing ciphers are found to be insecure. Depending on
precisely which ciphers are available to a process, the list may be reduced.
Copy link

@coderabbitai coderabbitai bot Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

Mozilla Server Side TLS configuration guidelines canonical URL current version

💡 Result:

Canonical UI: https://ssl-config.mozilla.org/ [1]

Machine-readable (canonical JSON): https://statics.tls.security.mozilla.org/server-side-tls-conf.json [2]

Current guideline version (published/used in generator examples): v5.7. [3][4]

Sources:

  • Mozilla SSL Config Generator (site). [1]
  • Mozilla Server Side TLS JSON location (statics.tls.security.mozilla.org). [2]
  • Examples / changelog referencing guideline v5.7 (GitHub / generator outputs). [3][4]

Update stale Mozilla TLS v5.0 reference to canonical source

The documentation references "version 5.0 (2019-06-28)" which is now outdated; the current version is v5.7. Update to use the canonical, unversioned reference instead:

- The profiles are currently based on version 5.0 of the Mozilla Server Side TLS
- configuration guidelines (released 2019-06-28) with TLS 1.3 ciphers added for
- forward compatibility. See: https://ssl-config.mozilla.org/guidelines/5.0.json
+ The profiles are currently based on Mozilla Server Side TLS configuration
+ guidelines with TLS 1.3 ciphers added for forward compatibility. See:
+ https://ssl-config.mozilla.org/
🤖 Prompt for AI Agents
In
payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
around lines 424 to 433, the docs reference "version 5.0 (2019-06-28)" and link
to a versioned JSON; update the text to refer to the canonical Mozilla Server
Side TLS configuration guidelines without a specific version and replace the
versioned URL with the unversioned canonical URL (for example
https://ssl-config.mozilla.org/guidelines/) so the doc always points to the
current guidance.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will follow up with an updated PR. I did not want to change any of the supported ciphers in this PR, only update the documentation.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sanchezl Thanks for clarifying your approach! That makes perfect sense—keeping the documentation improvements separate from any cipher list or profile changes maintains a clean separation of concerns. Looking forward to the follow-up PR to update the Mozilla TLS guideline reference to the canonical source.

@everettraven
Copy link
Contributor

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Dec 4, 2025
@openshift-ci-robot
Copy link

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aws-ovn
/test e2e-aws-ovn-hypershift
/test e2e-aws-ovn-hypershift-conformance
/test e2e-aws-ovn-techpreview
/test e2e-aws-serial-1of2
/test e2e-aws-serial-2of2
/test e2e-aws-serial-techpreview-1of2
/test e2e-aws-serial-techpreview-2of2
/test e2e-azure
/test e2e-gcp
/test e2e-upgrade
/test e2e-upgrade-out-of-change

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Dec 4, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: everettraven

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

The pull request process is described here

Needs approval from an approver in each of these files:

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Dec 4, 2025
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Dec 5, 2025

@sanchezl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/e2e-aws-serial-1of2 92bb14e link true /test e2e-aws-serial-1of2
ci/prow/e2e-aws-ovn-techpreview 92bb14e link true /test e2e-aws-ovn-techpreview

Full PR test history. Your PR dashboard.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants