-
Notifications
You must be signed in to change notification settings - Fork 581
NO-JIRA: update TLS security profile documentation for clarity and consistency #2595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
|
Hello @sanchezl! Some important instructions when contributing to openshift/api: |
WalkthroughAdded a new public field Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
✨ Finishing touches
🧪 Generate unit tests (beta)
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 Comment |
There was a problem hiding this 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
📒 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, andModernTLSProfiletypes 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.
ce5b632 to
be117b4
Compare
|
@sanchezl: This pull request explicitly references no jira issue. In response to this:
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. |
There was a problem hiding this 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 NOTEFor 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
📒 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 accurateThe 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 concreteTLSProfilesentries (minTLSVersion and cipher lists) without changing behavior. This improves clarity while keeping the API stable.Also applies to: 121-158
everettraven
left a comment
There was a problem hiding this 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
be117b4 to
4479e6d
Compare
There was a problem hiding this 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 unsupportedThe 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 maximumminTLSVersionofVersionTLS12, 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
📒 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.goconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlconfig/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlconfig/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yamlmachineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yamlmachineconfiguration/v1/zz_generated.featuregated-crd-manifests/kubeletconfigs.machineconfiguration.openshift.io/AAA_ungated.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamloperator/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 clearThe updated
tlsSecurityProfiledocs (custom example withminTLSVersion, expanded Old/Intermediate/Modern descriptions, and thetypetext 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 semanticsThe refreshed Swagger docs for
IntermediateTLSProfile,ModernTLSProfile,OldTLSProfile,TLSProfileSpec.minTLSVersion, andTLSSecurityProfilelook 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_generatedprefix). 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
minTLSVersionenum field is properly defined with all four TLS versions (1.0–1.3). However, since this is a generated file, confirm that:
- The underlying Go type in the API package has been updated with this field
- The code generator was re-run to produce this manifest
- All related CRD manifests across
config/v1/andoperator/v1/directories include consistent schema changes
...nerated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
Show resolved
Hide resolved
4479e6d to
37be723
Compare
There was a problem hiding this 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.goconfig/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: VersionTLS12Also 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.2Use VersionTLS12 instead of VersionTLS11 in the example to avoid suggesting TLS 1.1.
- minTLSVersion: VersionTLS11 + minTLSVersion: VersionTLS12config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)
308-314: Prefer TLS 1.2 in Custom exampleSwitch example minTLSVersion to VersionTLS12 to avoid normalizing TLS 1.1 in guidance.
- minTLSVersion: VersionTLS11 + minTLSVersion: VersionTLS12config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml (1)
239-245: Update Custom example to TLS 1.2Use 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
📒 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.yamlconfig/v1/zz_generated.swagger_doc_generated.goopenapi/generated_openapi/zz_generated.openapi.gopayload-manifests/crds/0000_10_config-operator_01_apiservers-Default.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlconfig/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlmachineconfiguration/v1/zz_generated.featuregated-crd-manifests/kubeletconfigs.machineconfiguration.openshift.io/AAA_ungated.yamloperator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yamloperator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlmachineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlconfig/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yamlpayload-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
minTLSVersionfield 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
VersionTLS13for 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. IncludingVersionTLS13in the schema while documenting the practical limit toVersionTLS12is 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 mappingThe updated summary succinctly ties
IntermediateTLSProfileto the intermediate Mozilla TLS configuration, which is sufficient at this level; no issues.
2953-2955: Modern profile doc succinctly captures its Mozilla “modern” basisThe description clearly communicates that
ModernTLSProfiletracks the Mozilla modern profile; nothing to change here.
2961-2963: Old profile doc adequately scopes its Mozilla “old” intentThe
OldTLSProfiletext correctly positions this as the legacy/compat profile; clear and consistent with the other profile summaries.
2969-2973:minTLSVersiondescription is clearer with an explicit exampleThe revised
TLSProfileSpec.minTLSVersiondoc 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 usefulThe new
type,old,intermediate,modern, andcustomdescriptions:
- Reference the exact Mozilla TLS 5.0 guideline basis.
- Spell out equivalence to a
Customprofile viaminTLSVersionand 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.
...z_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
Show resolved
Hide resolved
...g/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yaml
Show resolved
Hide resolved
...onfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml
Show resolved
Hide resolved
...onfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yaml
Show resolved
Hide resolved
operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml
Show resolved
Hide resolved
payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
Show resolved
Hide resolved
everettraven
left a comment
There was a problem hiding this 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.
37be723 to
92bb14e
Compare
There was a problem hiding this 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 minTLSVersionThe description still says “only Old and Intermediate profiles are currently supported” and that the maximum available
minTLSVersionisVersionTLS12, but this schema and the subfield docs now exposeModernand allowVersionTLS13. 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 referenceSame 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 referenceThis 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 linkSame 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 pinThis 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' -C2config/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 docsAllowing 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 cautionListing 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.1Mirror the warning about deprecated TLS 1.0/1.1 in this TechPreview CRD as well to discourage insecure choices.
382-420: Legacy “Old” profile cautionConsider 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 wellAdd a one-line deprecation advisory in minTLSVersion description to discourage insecure configs.
2071-2109: Old profile: add explicit cautionRecommend 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 noticeReplicate the warning on deprecated protocol versions to steer users to TLS 1.2+.
382-420: Old profile: cautionary note suggestedAs 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 advisoryAdd one-line advisory on TLS 1.0/1.1 deprecation to the minTLSVersion description here too.
382-420: Old mapping: add explicit cautionRecommend 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
📒 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.yamlconfig/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/AAA_ungated.yamlmachineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_kubeletconfigs.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamloperator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yamlconfig/v1/zz_generated.swagger_doc_generated.goconfig/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-Default.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlconfig/v1/types_tlssecurityprofile.gopayload-manifests/crds/0000_80_machine-config_01_kubeletconfigs.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-Default.crd.yamlconfig/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 TLSProfilesThe new
intermediate,modern, andolddescriptions that spell out the equivalent Custom profile (includingminTLSVersionand cipher lists) align with the GoTLSProfilesmap 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 consistentThe updated comments for
TLSSecurityProfile,Old/Intermediate/ModernTLSProfile,TLSProfileType, andTLSProfilescorrectly describe the Mozilla TLS 5.0 basis, intent-based behavior, and the exact Custom-equivalentminTLSVersion/cipher lists that match theTLSProfilesmap andTLSProtocolVersionenum. No functional concerns here.config/v1/zz_generated.swagger_doc_generated.go (1)
2847-2888: Swagger TLS profile docs correctly mirror core type commentsThe updated SwaggerDoc entries for
Old/Intermediate/ModernTLSProfile,TLSProfileSpec.minTLSVersion, andTLSSecurityProfilematch 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 clearThe
tlsSecurityProfiledescription, Custom example (includingminTLSVersion), and the detailedold/intermediate/modernequivalence text all line up with the GoTLSSecurityProfile/TLSProfilesdefinitions 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 minTLSVersionIncluding minTLSVersion in the Custom example improves clarity and forward-compatibility. No issues.
344-353: Equivalence note is helpfulStating that Intermediate ≅ Custom with minTLSVersion: VersionTLS12 reduces ambiguity. Looks good.
369-378: Modern profile mapping is clearClear 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: LGTMThe example with minTLSVersion improves usability.
344-353: Intermediate ≅ Custom(TLS1.2) clarityClear, consistent with other CRDs.
369-378: Modern ≅ Custom(TLS1.3) clarityConsistent and correct.
operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers.crd.yaml (3)
1997-2003: Custom example inclusion: OKminTLSVersion in example improves operator UX.
2033-2054: Intermediate mapping doc: OKClear equivalence and cipher ordering.
2058-2067: Modern mapping doc: OKNo issues.
payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (3)
308-314: Custom example: LGTMConsistent with other manifests.
344-353: Intermediate ≅ Custom(TLS1.2) clarityLooks good.
369-378: Modern ≅ Custom(TLS1.3) clarityLooks good.
config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (3)
308-314: Custom example: LGTMConsistent, helpful example.
344-353: Intermediate mapping clarityOK.
369-378: Modern mapping clarityOK.
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.
| 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 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.
| 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
/lgtm |
|
Scheduling tests matching the |
|
[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 |
|
@sanchezl: The following tests failed, say
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. |
Update TLS security profile documentation for clarity and consistency in preparation for possibly updating the pre-defined TLS profiles in an upcoming release.