API-1844: Update KMSConfig to allow manualy managed kms plugins #2622
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
openshift-ci-robot
added
the
jira/valid-reference
|
@ardaguclu: This pull request references API-1844 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set. DetailsIn 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. |
|
Hello @ardaguclu! Some important instructions when contributing to openshift/api: |
|
/hold |
📝 WalkthroughWalkthroughThe PR introduces Manual/External KMS support alongside deprecated AWS KMS. It adds a 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Comment |
openshift-ci
bot
added
do-not-merge/hold
|
@ardaguclu: This pull request references API-1844 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set. DetailsIn 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. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
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 (2)
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)
161-195: Endpoint CEL validation likely allows whitespace later in the string; confirm intent.
self.matches('^unix:///(@[^/\\s]+|[^@\\s].*)$')prevents leading whitespace afterunix:///, but.*can still match whitespace later (e.g.,unix:///var/run/kms plugin.sock). If whitespace should be invalid anywhere, tighten the regex (e.g., use[^\\s]*for the remainder).config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (1)
161-195: Keep endpoint CEL validation consistent with desired whitespace policy.Same note as the non-featuregated CRD:
[^@\\s].*can allow whitespace after the first character; tighten if you want to reject whitespace anywhere in the endpoint.
🧹 Nitpick comments (5)
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
171-182: Consider stricter endpoint path validation.The regex pattern allows spaces in socket paths after the first character (e.g.,
unix:///my socket) and doesn't enforce absolute filesystem paths starting with/as the description states. The pattern[^@\s].*only prevents the first character from being@or whitespace.If the intent is to strictly enforce absolute paths and prevent spaces anywhere in the path, consider updating the regex to:
^unix:///(@[^/\s]+|/[^\s]+)$This would:
- Require filesystem paths to start with
/(matching "absolute filesystem path" in the description)- Disallow spaces throughout the entire path
payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)
171-182: Redundant validation between pattern and x-kubernetes-validations.The
x-kubernetes-validationsrule at lines 180-182 checksself.startsWith('unix:///'), which is already enforced by thepatternat line 178. The pattern^unix:///(@[^/\s]+|[^@\s].*)$ensures the string starts withunix:///through the^anchor.Consider removing the redundant
startsWithvalidation or using a single comprehensive validation approach. The pattern validation alone is sufficient for the format check.Additionally, the same path validation refinement mentioned for other CRD variants applies here - consider stricter enforcement of absolute paths.
payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
171-182: Same validation redundancy as DevPreviewNoUpgrade payload variant.The combination of
patternandx-kubernetes-validations.startsWithcreates redundant checks. The pattern already enforces theunix:///prefix requirement.config/v1/types_kmsencryption.go (1)
15-23: Endpoint validation is consistent with CRD definitions.The kubebuilder validation tags match the CRD OpenAPI schema validations. The XValidation regex correctly uses Go string escaping (
\\s).However, the same validation refinement suggestion applies: consider stricter enforcement to require absolute paths starting with
/and disallow spaces throughout the path, matching the description's intent of "absolute filesystem path."openapi/openapi.json (1)
7977-7981: Consider adding schema-level validation for endpoint format.The endpoint field description documents the required format (
unix:///path/to/socketorunix:///@abstractsocket), but this validation is not enforced by the schema itself (nopatternorformatconstraint). Moving validation to the schema level would improve API usability and catch errors earlier.Consider adding a regex pattern to validate the Unix socket endpoint format:
"endpoint": { "description": "endpoint specifies the unix domain socket endpoint...", "type": "string", "pattern": "^unix:///.+$" }
📜 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/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml(4 hunks)config/v1/types_kmsencryption.go(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.deepcopy.go(1 hunks)config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml(1 hunks)config/v1/zz_generated.swagger_doc_generated.go(1 hunks)openapi/generated_openapi/zz_generated.openapi.go(1 hunks)openapi/openapi.json(2 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml(1 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(1 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml(1 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/zz_generated.deepcopy.goconfig/v1/zz_generated.swagger_doc_generated.goconfig/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlconfig/v1/types_kmsencryption.goconfig/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlopenapi/openapi.jsonopenapi/generated_openapi/zz_generated.openapi.gopayload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
🔇 Additional comments (8)
config/v1/zz_generated.deepcopy.go (1)
43-51: Deepcopy change looks correct for the newKMSConfigshape (shallow-copy-safe).
**out = **inis the expected deepcopy-gen pattern here, andKMSConfig.DeepCopyIntobeing*out = *inindicates it’s safe with the current fields.config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (1)
7-132: Test updates align with the new External/endpoint schema and cover key failure modes.config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
183-194: LGTM - Clean migration to External provider model.The type field correctly defaults to
External, and makingendpointrequired ensures users provide the necessary configuration. The single-value enum is appropriate for this migration phase.config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)
171-194: Validation and field definitions are consistent with CustomNoUpgrade variant.The endpoint field validations and type field configuration match the CustomNoUpgrade CRD variant. The same optional refinement regarding stricter path validation applies here.
payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)
171-182: Consistent validation structure with other variants.The endpoint validation follows the same pattern as other payload manifest variants, including the redundant
startsWithcheck alongside the comprehensive pattern validation.config/v1/types_kmsencryption.go (2)
6-13: LGTM - Type field properly configured.The
Typefield correctly defaults toExternaland is marked optional, allowing the default behavior to take effect when unspecified. The enum restriction toExternalonly is appropriate for this migration.
27-34: LGTM - Clean enum definition.The
KMSProviderTypeenum restriction andExternalKMSProviderconstant properly reflect the External-only KMS provider model. The migration from AWS-specific types is breaking but justified by the tech preview status noted in the PR description.openapi/openapi.json (1)
9856-9856: Verify scope of policyType changes.The policyType description update (hunk 2) appears unrelated to the KMS configuration changes described in the PR objectives. Confirm whether this change is intentional and part of this PR's scope or a merge artifact.
|
@ardaguclu: This pull request references API-1844 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set. DetailsIn 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. |
|
@ardaguclu: This pull request references API-1844 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set. DetailsIn 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.
Actionable comments posted: 4
♻️ Duplicate comments (2)
openapi/generated_openapi/zz_generated.openapi.go (1)
15140-15146:typefield still missing Enum and DefaultThe previously flagged issue persists: the
typefield lacksEnum: []interface{}{"External"}andDefault: "External"in the schema, despite the description indicating these constraints. Fix this at the generator or source annotation level.openapi/openapi.json (1)
7973-7986: Remove invalid empty-string default for requiredendpoint(and tighten validation).
endpointis required (Line 7973-7975) but defaults to""(Line 7980), which is not a valid unix socket endpoint. Also,typereads like an enum with a default but isn’t encoded as one."required": [ "endpoint" ], "properties": { "endpoint": { "description": "endpoint specifies the unix domain socket endpoint for communicating with the external KMS plugin. The endpoint must follow the format \"unix:///path/to/socket\" or \"unix:///@abstractsocket\" for abstract sockets. The path must start with \"unix:///\" followed by either an absolute filesystem path or an abstract socket name (prefixed with @).", "type": "string", - "default": "" + "minLength": 1 + // Consider also adding a pattern for unix domain sockets if compatible with your validation strategy: + // "pattern": "^unix:///.*|^unix:///@.+" }, "type": { "description": "type defines the kind of KMS provider. Valid values are \"External\". When set to External, the KMS provider is an external plugin accessed via unix socket. When not specified, defaults to External.", - "type": "string" + "type": "string", + "enum": ["External"], + "default": "External" } }
📜 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/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml(4 hunks)config/v1/types_kmsencryption.go(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.deepcopy.go(1 hunks)config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml(1 hunks)config/v1/zz_generated.swagger_doc_generated.go(1 hunks)openapi/generated_openapi/zz_generated.openapi.go(1 hunks)openapi/openapi.json(2 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml(1 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(1 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
- config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
- config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
- 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:
config/v1/zz_generated.deepcopy.gopayload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlconfig/v1/zz_generated.swagger_doc_generated.goconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlopenapi/generated_openapi/zz_generated.openapi.goconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlconfig/v1/types_kmsencryption.gopayload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlopenapi/openapi.json
🔇 Additional comments (5)
config/v1/zz_generated.deepcopy.go (1)
43-50: Confirm shallow-copy semantics forKMSConfigare safe here
**out = **inperforms a value copy of theKMSConfigstruct. This is fine ifKMSConfigonly contains value fields (e.g., strings/enums), but would be incorrect if it contains slices/maps/pointers that need deep copy. Since this is generated, please just verify the currentKMSConfigshape matches this assumption.payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
170-195:endpoint.minLength: 9likely rejects validunix:///aendpoints; regex also allows whitespaceIf
unix:///ashould be valid,minLengthshould be8(not9). Also, the current rule allows whitespace after the first character in the filesystem-path branch ([^@\s].*). Consider tightening to disallow whitespace anywhere.- minLength: 9 + minLength: 8 ... - rule: self.matches('^unix:///(@[^/\s]+|[^@\s].*)$') + rule: self.matches('^unix:///(@[^/\s]+|[^@\s][^\s]*)$')Likely an incorrect or invalid review comment.
config/v1/zz_generated.swagger_doc_generated.go (1)
2194-2198: KMSConfig swagger doc update matches the new External+endpoint model
This looks consistent with the API shift to an external KMS plugin over a unix-domain socket.config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
161-195: The endpoint regex is correct as written;\sis properly supported in Kubernetes CEL regex (which uses RE2)Kubernetes' CEL
matches()function uses the RE2 regex dialect via cel-go, which fully supports\sas a whitespace character class. The original pattern'^unix:///(@[^/\s]+|[^@\s].*)$'is valid and works as intended. No change is needed.config/v1/types_kmsencryption.go (1)
26-34: External-only provider enum + renamed const look consistent with the new API.
RestrictingKMSProviderTypetoExternaland usingExternalKMSProvideraligns with the CRD defaulting/enum.
payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
Show resolved
Hide resolved
|
@ardaguclu: This pull request references API-1844 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set. DetailsIn 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.
Actionable comments posted: 2
♻️ Duplicate comments (5)
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)
171-195: Generated TechPreview CRD still has weaker/different endpoint regex than payload CRDs.This file uses
rule: self.matches('^unix:///(@[^/ ]+|[^@ ][^ ]*)$'), while the payload CRDs in this PR use the\s-based regex. Please update the source definition and re-run generation so TechPreviewNoUpgrade’s generated CRD matches the payload and fully rejects whitespace (not just spaces).openapi/generated_openapi/zz_generated.openapi.go (1)
15139-15156: Generated schema still doesn’t enforcetypeconstraints (enum/default) and may under-validateendpoint
type’s description says it defaults to and only allows"External", but the schema doesn’t setEnum/Default, so clients won’t get validation from OpenAPI (and may accept invalid values). Also consider encoding the unix-socket constraints forendpointasPattern/MinLength(not just in the description) if those markers exist on the Go type. Since this is generated, please fix the source markers (or generator mapping) and regenerate, rather than editing this file directly.config/v1/types_kmsencryption.go (1)
15-23: Update regex to use standard escape sequences.The endpoint validation regex currently uses literal space characters, which is inconsistent with the payload CRD manifest at
payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(line 182). Use\sescape sequences for consistency and regenerate all CRD manifests.Apply this diff:
- // +kubebuilder:validation:XValidation:rule="self.matches('^unix:///(@[^/ ]+|[^@ ][^ ]*)$')",message="endpoint must follow the format 'unix:///path' or 'unix:///@abstractname'" + // +kubebuilder:validation:XValidation:rule="self.matches('^unix:///(@[^/\\s]+|[^@\\s][^\\s]*)$')",message="endpoint must follow the format 'unix:///path' or 'unix:///@abstractname'"Note: The
omitemptytag on the required field is intentional per project linting requirements.openapi/openapi.json (2)
7973-7986: Remove invalid empty-string default for requiredendpoint(and consider constrainingtype).
endpointis required (Line 7973-7975) but has"default": ""(Line 7980), which contradicts the described unix socket format and can generate invalid defaults in clients. Also,typeclaims only"External"is valid but isn’t constrained/defaulted in the schema."required": [ "endpoint" ], "properties": { "endpoint": { "description": "endpoint specifies the unix domain socket endpoint ...", "type": "string", - "default": "" + "minLength": 1 }, "type": { "description": "type defines the kind of KMS provider. Valid values are \"External\". ... When not specified, defaults to External.", - "type": "string" + "type": "string", + "enum": ["External"], + "default": "External" } }
9855-9859: Don’t default requiredpolicyTypeto""; enforce allowed values.
The description sayspolicyTypeis required and only allows specific values (Line 9855-9856), but the schema sets"default": ""(Line 9858)."policyType": { "description": "policyType is a required field ... Allowed values are \"PublicKey\", \"FulcioCAWithRekor\", and \"PKI\". ...", "type": "string", - "default": "" + "enum": ["PublicKey", "FulcioCAWithRekor", "PKI"] },Also ensure the parent object’s
"required"list includes"policyType"(not shown in this hunk).
🧹 Nitpick comments (1)
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)
171-182: Generated file - review source instead.This is an auto-generated CRD manifest. Any validation or regex pattern issues should be addressed in the source Go file
config/v1/types_kmsencryption.go, which will then regenerate this manifest.
📜 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/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml(4 hunks)config/v1/types_kmsencryption.go(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.deepcopy.go(1 hunks)config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml(1 hunks)config/v1/zz_generated.swagger_doc_generated.go(1 hunks)openapi/generated_openapi/zz_generated.openapi.go(1 hunks)openapi/openapi.json(2 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml(1 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(1 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml(1 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/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlopenapi/generated_openapi/zz_generated.openapi.goconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlconfig/v1/zz_generated.swagger_doc_generated.goconfig/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlconfig/v1/zz_generated.deepcopy.goconfig/v1/types_kmsencryption.goopenapi/openapi.json
🔇 Additional comments (13)
payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)
171-195: Endpoint-based External KMS schema looks good in payload CRD.payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
171-195: Payload CustomNoUpgrade CRD endpoint-based External KMS schema looks good.config/v1/zz_generated.deepcopy.go (1)
43-50: No action needed. TheKMSConfigstruct contains only value types (TypeasKMSProviderType, a string alias, andEndpointasstring), making the shallow copy**out = **insafe.config/v1/zz_generated.swagger_doc_generated.go (1)
2194-2202: KMSConfig SwaggerDoc looks consistent with the new External+endpoint model
Docs clearly communicatetype=Externaland the two supported unix socket endpoint forms; this matches the direction of the CRD/test updates.config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (4)
8-39: Good: positive External endpoint case + clear rejection of non-unix:///...endpoints
The success path and the “missing unix scheme” failure case directly exercise the new endpoint validation behavior.
40-59: Good: test asserts kms is forbidden unlessspec.encryption.type=KMS, and endpoint is required
These cases validate the key guardrail and the required-ness ofendpoint.
60-110: Verify defaulting + error-message stability in the test harness
IfexpectedErrorrequires exact matching, messages likespec.encryption.kms.endpoint: Required value(and similar) can vary across validation layers/versions; consider ensuring the harness matches substrings (or adjust expected strings accordingly).
111-143: Endpoint edge-case coverage is solid; verify abstract socket format is truly supported end-to-end
Schema validation allowsunix:///@abstractname; please confirm the downstream KMS client/dialer path supports this format (not just admission).config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
161-195: CRD schema update is coherent: External-only + requiredendpointwith format validation
The required field, enum restriction, defaulting toExternal, and CEL rule appear consistent with the updated tests/docs; please just ensure the chosen endpoint regex/length bounds match the intended supported plugin endpoint conventions.config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)
183-195: LGTM: External provider configuration.The type field correctly defaults to External with appropriate enum constraints, and the required field change from AWS-specific to endpoint aligns with the new External KMS provider model.
config/v1/types_kmsencryption.go (3)
6-13: LGTM: Type field updated correctly.The Type field correctly defaults to External, with updated description and validation. The
omitemptytag is intentional per this project's linting requirements to ensure consistent behavior between structured and unstructured clients.
27-29: LGTM: KMSProviderType correctly updated.The enum validation correctly restricts the type to External, aligning with the removal of AWS-specific provider support.
32-33: LGTM: Constant correctly renamed.The constant rename from
AWSKMSProvidertoExternalKMSProviderwith value "External" correctly reflects the new provider model. This breaking change is acceptable given the tech preview status and absence of controllers watching these resources.
...nerated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
Outdated
Show resolved
Hide resolved
payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
Outdated
Show resolved
Hide resolved
|
verify-crd-schema and verify-crdify failures are valid. Because we are removing aws related fields. |
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (5)
config/v1/types_kmsencryption.go (1)
15-23: Tighten endpoint regex to reject all whitespace (not just spaces).
self.matches('^unix:///(@[^/ ]+|[^@ ][^ ]*)$')rejects literal spaces but still allows tabs/newlines. If the intent is “no whitespace anywhere”, switch to\s(escaped for CEL).- // +kubebuilder:validation:XValidation:rule="self.matches('^unix:///(@[^/ ]+|[^@ ][^ ]*)$')",message="endpoint must follow the format 'unix:///path' or 'unix:///@abstractname'" + // +kubebuilder:validation:XValidation:rule="self.matches('^unix:///(@[^/\\s]+|[^@\\s][^\\s]*)$')",message="endpoint must follow the format 'unix:///path' or 'unix:///@abstractname'"payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
170-195: CRD endpoint validation should reject all whitespace (use\\s).Mirror the stricter pattern used in the Go type validation so tabs/newlines aren’t accepted:
- rule: self.matches('^unix:///(@[^/ ]+|[^@ ][^ ]*)$') + rule: self.matches('^unix:///(@[^/\\s]+|[^@\\s][^\\s]*)$')config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (1)
171-195: Alignkms.endpointCEL regex across all CRD variants (featuregated/generated/payload).
This manifest’srule: self.matches('^unix:///(@[^/ ]+|[^@ ][^ ]*)$')excludes only literal spaces; earlier review feedback noted other CRDs use\s-style exclusion—please make them identical by updating the generator source and regenerating outputs.#!/bin/bash set -euo pipefail # Compare all CEL rules for endpoint validation across the repo rg -n "endpoint must follow the format|self\.matches\('\^unix:///" -S echo echo "Unique regex rules found:" rg -n "self\.matches\('\^unix:///[^\n]*'\)" -S | sed -E "s/.*self\.matches\('([^']+)'\).*/\1/" | sort -uconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
171-195: KMS endpoint/type schema update is consistent here; keep it generator-driven.
This matches the featuregated manifest (endpoint required, type default/enumExternal, same CEL regex). If you adjust the endpoint regex for consistency, ensure it’s done in the generator source and regen updates this file too.openapi/openapi.json (1)
9854-9858: Remove invalidpolicyTypedefault""and model allowed values explicitly.
This still contradicts the description (“required” + allowed values) and can lead to invalid objects being considered “default-valid” by generators."policyType": { "description": "policyType is a required field specifies the type of the policy for verification. This field must correspond to how the policy was generated. Allowed values are \"PublicKey\", \"FulcioCAWithRekor\", and \"PKI\". When set to \"PublicKey\", the policy relies on a sigstore publicKey and may optionally use a Rekor verification. When set to \"FulcioCAWithRekor\", the policy is based on the Fulcio certification and incorporates a Rekor verification. When set to \"PKI\", the policy is based on the certificates from Bring Your Own Public Key Infrastructure (BYOPKI).", "type": "string", - "default": "" + "enum": ["PublicKey", "FulcioCAWithRekor", "PKI"] },Also verify the enclosing schema’s
"required"includes"policyType"(outside this hunk).
🧹 Nitpick comments (1)
config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (1)
8-143: Test updates cover External+endpoint and key failure modes well.Optional: add one negative case for
endpointcontaining\t/\nif you adopt the\\s-based regex.
📜 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/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml(4 hunks)config/v1/types_kmsencryption.go(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.deepcopy.go(1 hunks)config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml(1 hunks)config/v1/zz_generated.swagger_doc_generated.go(1 hunks)openapi/generated_openapi/zz_generated.openapi.go(1 hunks)openapi/openapi.json(2 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml(1 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(1 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml(1 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/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlconfig/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlconfig/v1/zz_generated.deepcopy.goconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlconfig/v1/types_kmsencryption.goopenapi/openapi.jsonconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlconfig/v1/zz_generated.swagger_doc_generated.goopenapi/generated_openapi/zz_generated.openapi.go
🔇 Additional comments (8)
config/v1/types_kmsencryption.go (1)
6-13: External-only provider typing/defaulting looks consistent.Also applies to: 26-34
config/v1/zz_generated.deepcopy.go (1)
43-50: DeepCopyInto KMSConfig shallow-copy is correct with current value-only fields.config/v1/zz_generated.swagger_doc_generated.go (1)
2194-2198: KMSConfig SwaggerDoc looks aligned with the new External+endpoint API surface.
Docs now correctly describetype=Externaland the unix socketendpointformats. Since this is generated, just ensure the source-of-truth type comments/validation inconfig/v1/types_kmsencryption.gomatch this wording before regen.config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)
170-195: KMS schema update looks consistent (endpoint + External-only type); keep validation in sync after source change.
This matches the TechPreview manifest, including the endpoint validation rule; if you adjust the regex in the Go source, regenerate this file too to keep DevPreview/TechPreview identical.payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)
170-195: Payload CRD aligns with generated schema; ensure regeneration after any regex tweak.
Given this is a payload manifest, please regenerate from the same source change (if you move to\s) to avoid subtle drift between payload vs zz_generated manifests.payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)
170-195: Same endpoint validation consideration applies here (space-only exclusion).
If the intent is “no whitespace”, prefer a source-level\sregex and regenerate to update this payload file as well.config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)
170-195: Endpoint regex blocks spaces but not tabs; however, this is not a practical concern.The regex
^unix:///(@[^/ ]+|[^@ ][^ ]*)$does match only literal spaces and not other whitespace. However:
- Filesystem paths cannot contain newlines (kernel restriction), and tabs in socket paths are extraordinarily rare in practice.
- The suggested
\sfix is problematic: it would match newlines, which could break YAML multiline string parsing that occurs before validation.- The test suite (in
config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml) explicitly validates rejection of spaces in paths, confirming the intent is deliberate.- The codebase pattern: No other CEL validations use
\s; explicit character classes like[0-9]are preferred, suggesting intentional specificity.The current regex is fit for purpose. If stricter whitespace handling is desired, consider documenting the intentional choice in the source file comment rather than introducing a regex that could have unintended side effects.
openapi/openapi.json (1)
7971-7986: ConstrainKMSConfig.typeto the documented value (and ensure endpoint validation exists).
Right now"type"is an unconstrained string while the description says only"External"is valid and defaulted when omitted. Consider enforcing that withenum(and optionallydefault) so generated clients/validation can’t accept arbitrary values. Also,endpointis required but shown without anypattern/length constraints—ensure those validations are actually present in this schema if they’re intended."properties": { "endpoint": { "description": "endpoint specifies the unix domain socket endpoint for communicating with the external KMS plugin. The endpoint must follow the format \"unix:///path/to/socket\" for filesystem-based sockets or \"unix:///@abstractname\" for abstract sockets.", "type": "string" }, "type": { "description": "type defines the kind of KMS provider. Valid values are \"External\". When set to External, the KMS provider is an external plugin accessed via unix socket. When not specified, defaults to External.", - "type": "string" + "type": "string", + "enum": ["External"], + "default": "External" } }
|
/cc @flavianmissi |
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (3)
openapi/generated_openapi/zz_generated.openapi.go (1)
15140-15146: [Duplicate] OpenAPI schema still missing Enum and Default fortypefieldThe generated schema lacks
Enum: ["External"]andDefault: "External"despite the description stating "defaults to External". This is the same issue flagged in the previous review.The source markers (
+kubebuilder:default=Externaland+kubebuilder:validation:Enum=External) are not propagating to the generated OpenAPI schema, weakening the published API contract. Clients cannot rely on schema-level validation or defaulting.Verify that the source markers are correctly applied and regenerate the schema. If the type-level Enum marker is not being recognized, consider applying it directly to the field.
config/v1/types_kmsencryption.go (1)
16-24: TightenendpointCEL regex to match documentedunix:///path/unix:///@namemore precisely. The current pattern (a) allowsunix:////...via the filesystem branch and (b) only blocks literal spaces, not all whitespace.- // +kubebuilder:validation:XValidation:rule="self.matches('^unix:///(@[^/ ]+|[^@ ][^ ]*)$')",message="endpoint must follow the format 'unix:///path' or 'unix:///@abstractname'" + // +kubebuilder:validation:XValidation:rule="self.matches('^unix:///(@[^/\\s]+|[^@/\\s][^\\s]*)$')",message="endpoint must follow the format 'unix:///path' or 'unix:///@abstractname'"After updating the Go type, regenerate the CRD/payload manifests so all three stay in sync. (CEL regex escape semantics vary by engine/version, so please double-check this against the apiserver’s CEL implementation.)
openapi/openapi.json (1)
9854-9858: policyType:default: ""contradicts “required field” and allowed valuesThis should either have no default (since it’s required) or be constrained to the allowed values (and default to one of them only if you truly want a default).
"policyType": { "description": "policyType is a required field specifies the type of the policy for verification. This field must correspond to how the policy was generated. Allowed values are \"PublicKey\", \"FulcioCAWithRekor\", and \"PKI\". When set to \"PublicKey\", the policy relies on a sigstore publicKey and may optionally use a Rekor verification. When set to \"FulcioCAWithRekor\", the policy is based on the Fulcio certification and incorporates a Rekor verification. When set to \"PKI\", the policy is based on the certificates from Bring Your Own Public Key Infrastructure (BYOPKI).", - "type": "string", - "default": "" + "type": "string", + "enum": ["PublicKey", "FulcioCAWithRekor", "PKI"] },Also ensure the parent schema’s
"required"includes"policyType"if it’s truly mandatory.
🧹 Nitpick comments (3)
config/v1/zz_generated.deepcopy.go (1)
43-51: Keep DeepCopy semantics forAPIServerEncryption.KMS(avoid**out = **in). The current code is equivalent today, but it’s easy to accidentally lose deep-copy semantics ifKMSConfiglater gains reference fields. Prefer the standard pattern(*in).DeepCopyInto(*out)(via generator source), even if it compiles to the same thing now.func (in *APIServerEncryption) DeepCopyInto(out *APIServerEncryption) { *out = *in if in.KMS != nil { in, out := &in.KMS, &out.KMS *out = new(KMSConfig) - **out = **in + (*in).DeepCopyInto(*out) } return }config/v1/zz_generated.swagger_doc_generated.go (1)
2194-2198: Align Swagger text with schema constraints (required/wording).
Swagger doc says “unix socket” and doesn’t stateendpointis required; CRD/schema typically uses “unix domain socket” and makesendpointrequired + validated. Consider tweaking the strings for consistency.var map_KMSConfig = map[string]string{ "": "KMSConfig defines the configuration for the KMS instance that will be used with KMSEncryptionProvider encryption", - "type": "type defines the kind of KMS provider. Valid values are \"External\". When set to External, the KMS provider is an external plugin accessed via unix socket. When not specified, defaults to External.", - "endpoint": "endpoint specifies the unix domain socket endpoint for communicating with the external KMS plugin. The endpoint must follow the format \"unix:///path/to/socket\" for filesystem-based sockets or \"unix:///@abstractname\" for abstract sockets.", + "type": "type defines the kind of KMS provider. Valid values are \"External\". When set to External, the KMS provider is an external plugin accessed via a unix domain socket. When not specified, defaults to External.", + "endpoint": "endpoint specifies the unix domain socket endpoint for communicating with the external KMS plugin (required). The endpoint must follow the format \"unix:///path/to/socket\" for filesystem-based sockets or \"unix:///@abstractname\" for abstract sockets.", }openapi/generated_openapi/zz_generated.openapi.go (1)
15147-15155: Consider adding Pattern validation forendpointformatThe description specifies that the endpoint must follow the format
"unix:///path/to/socket"or"unix:///@abstractname", but the schema lacks aPatternfield to enforce this at validation time.Without a pattern constraint, invalid endpoints (e.g.,
"http://example.com"or"/path/to/socket") could pass schema validation, deferring errors to runtime.Consider adding a pattern in the source type definition, such as:
+kubebuilder:validation:Pattern=`^unix://(/|@).+$`Then regenerate the OpenAPI schema to include the
Patternfield.
📜 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/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml(4 hunks)config/v1/types_kmsencryption.go(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.deepcopy.go(1 hunks)config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml(1 hunks)config/v1/zz_generated.swagger_doc_generated.go(1 hunks)openapi/generated_openapi/zz_generated.openapi.go(1 hunks)openapi/openapi.json(2 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml(1 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(1 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.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:
config/v1/zz_generated.deepcopy.goconfig/v1/types_kmsencryption.goconfig/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-DevPreviewNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlconfig/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlconfig/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlopenapi/openapi.jsonpayload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlopenapi/generated_openapi/zz_generated.openapi.goconfig/v1/zz_generated.swagger_doc_generated.go
🔇 Additional comments (8)
config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (1)
161-195: KMS schema update looks consistent (External-only + endpoint required).config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (1)
8-143: CRD validation tests are solid, but error-message matching may be brittle across apiserver versions. If this test harness expects exact strings, consider using regexp/contains (if supported) or include the full field path prefix that kube-apiserver typically returns (e.g.,spec.encryption.kms.endpoint: Invalid value: ...).config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
161-195: KMS endpoint validation looks coherent; confirm regex matches intended formats.
endpointis required and validated with^unix:///(@[^/ ]+|[^@ ][^ ]*)$, which appears to coverunix:///pathandunix:///@abstractnameas documented. Please sanity-check edge cases you want to allow/forbid (e.g., abstract names with/, or any whitespace) since this is user-facing API validation.config/v1/types_kmsencryption.go (1)
6-15: External-only provider defaulting/enum looks consistent.Also applies to: 31-34
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)
171-195: Generated CRD changes reflect the newkms.endpoint+ External-only provider model. Please keep this file regenerated fromconfig/v1/types_kmsencryption.go(don’t hand-edit).config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)
171-195: Looks consistent with the TechPreviewNoUpgrade CRD:endpointrequired + External-only type/default (generated output).payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)
171-195: Payload-manifest CRD matches the new schema (endpoint required; External-only). If you adjust the Go regex, re-run generation so payload + zz_generated stay aligned.payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
171-195: CustomNoUpgrade payload CRD update is consistent with the other variants (endpoint required + External-only).
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
openapi/generated_openapi/zz_generated.openapi.go (1)
15140-15155: Validation constraints still missing from generated schema.The field names have been correctly updated (
type→managementModel,aws→endpoint), but the validation gaps identified in previous reviews persist:
managementModel(Lines 15140-15146): Description states "Valid values are "External"" but lacks:
Enum: []interface{}{"External"}to enforce the single valid valueDefault: "External"to provide the default
endpoint(Lines 15147-15153): Description specifies unix socket format patterns but lacks:
Pattern: "^unix:///.*$|^unix:///@.*$"to enforce the formatSince this is a generated file, add the missing kubebuilder markers to the source type definition in
config/v1/types_kmsencryption.go:
+kubebuilder:validation:Enum=Externalon themanagementModelfield+kubebuilder:default=Externalon themanagementModelfield+kubebuilder:validation:Pattern=^unix:///.*$|^unix:///@.*$on theendpointfieldThen regenerate the OpenAPI schema.
openapi/openapi.json (1)
7977-7984: Missing validation constraints issue previously raised.The prior review comment at lines 7973-7985 flagged that the OpenAPI schema lacks the validation constraints present in the source code (
config/v1/types_kmsencryption.go):
endpoint: missingminLength,maxLength, andpatternconstraintsmanagementModel: missingenumanddefaultvaluesEnsure the OpenAPI generation properly reflects the kubebuilder validation markers.
🧹 Nitpick comments (1)
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (1)
161-195: KMS endpoint + managementModel schema looks solidThe unix-domain-socket
endpointvalidation andmanagementModelenum/default cleanly enforce the external KMS plugin model, and the CEL regex correctly rejects abstract sockets and obvious bad formats. One possible (non-blocking) refinement would be to alignmaxLengthwith the underlying unix socket path limit to fail clearly at validation time rather than later in the KMS client, but the current bound is acceptable as-is.
📜 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/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml(4 hunks)config/v1/types_kmsencryption.go(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml(1 hunks)config/v1/zz_generated.deepcopy.go(1 hunks)config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml(1 hunks)config/v1/zz_generated.swagger_doc_generated.go(1 hunks)openapi/generated_openapi/zz_generated.openapi.go(1 hunks)openapi/openapi.json(2 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml(1 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml(1 hunks)payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
- payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.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:
config/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.yamlconfig/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlconfig/v1/zz_generated.swagger_doc_generated.goconfig/v1/types_kmsencryption.gopayload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlconfig/v1/zz_generated.deepcopy.goopenapi/generated_openapi/zz_generated.openapi.goconfig/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlconfig/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlopenapi/openapi.json
🔇 Additional comments (10)
config/v1/zz_generated.deepcopy.go (1)
42-51: DeepCopy change forKMSConfigis correctUsing
new(KMSConfig)plus**out = **inis appropriate now thatKMSConfigonly has value fields, and it avoids pointer aliasing. Generated code remains consistent with other simple structs.config/v1/types_kmsencryption.go (1)
5-25: KMSConfig shape and validation look consistent and sound
ManagementModel+ requiredEndpointwith the unix‑socket regex, length bounds, default, and docs all line up with the CRDs and tests. Theomitemptyon required fields matches this repo’s linter conventions.config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (1)
171-194: Feature‑gated CRD kms schema correctly mirrors the Go type
endpointandmanagementModeldefinitions (including requiredness, defaults, and CEL regex) are in sync withKMSConfigand the tests, so CRD and server‑side behavior stay aligned.config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)
171-194: TechPreview CRD kms block is consistent with source and other CRDsThe kms
endpointandmanagementModelfields, validations, and required list match the Go type and the feature‑gated CRD, keeping the API coherent across feature sets.config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (1)
8-133: KMS tests comprehensively exercise the new endpoint semanticsThe added cases cover valid configuration, defaulting of
managementModel, and the main failure modes (scheme, missing/empty endpoint, spaces, abstract sockets, and invalid pairing with non‑KMS type), which should give good confidence in the new validation logic.payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
161-195: Consistent KMS schema across feature setsThe
kmsblock (endpoint + managementModel + required:endpoint and validations) matches the DevPreview CRD, which keeps behavior consistent across feature sets and avoids drift. No additional issues spotted here.config/v1/zz_generated.swagger_doc_generated.go (1)
2194-2198: KMSConfig Swagger docs aligned with new External KMS modelThe updated
map_KMSConfigentries correctly describe the newmanagementModelandendpointfields and match the CRD semantics (external plugin viaunix:///path, no abstract sockets). This keeps generated Swagger/OpenAPI in sync with the refactored API.config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (3)
171-181: Endpoint validation correctly implements UNIX socket format requirements.The regex validation
^unix:///[^@ ][^ ]*$properly:
- Enforces the
unix:///prefix format- Prevents abstract Linux sockets (starting with
@) as documented- Rejects spaces in paths to avoid parsing ambiguities
- Works with the length constraints (minLength 9 ensures at least one character after the prefix)
This correctly transitions from AWS-specific fields to a generic External KMS endpoint model.
182-191: LGTM! Management model correctly restricted to External.The default value of
Externaland the enum constraint align with the transition away from AWS-specific KMS configurations. The description accurately reflects the External model using user-deployed KMS plugins with UNIX domain sockets and KMS V2 API.
192-194: Required field correctly updated for External KMS model.Making
endpointrequired (instead of the removed AWS-specific fields) is appropriate for the External KMS configuration. This ensures users must specify the UNIX socket endpoint when configuring KMS encryption.
|
@flavianmissi I've excluded abstract Linux paths from the validations (as we agreed upon). Could you PTAL?. |
|
Scheduling tests matching the |
|
/test e2e-aws-ovn |
|
/lgtm cancel @ardaguclu @flavianmissi While I appreciate the team review and LGTM, please don't Will get you a reviewer assigned |
Thank you for the comment. This doesn't look like the flow in other OCP repositories but the motivation makes sense to me. As prerequisite we need to merge our EP openshift/enhancements#1900 first (@JoelSpeed I've added you as api-approver, but we need to complete our reviews within the team first). |
|
No worries @ardaguclu, it's a different process that we are trialing and I expect more repos to take on in the future. I'm hoping we can make it more obvious later @yuqi-zhang is one of our API reviewers who's training up, he will take a first review pass here and on the EP, and once he's happy I'll take a look |
| // | ||
| // +unionDiscriminator | ||
| // +required | ||
| Type KMSProviderType `json:"type"` |
There was a problem hiding this comment.
For serialization safety and to adhere to v1 API guarantees, we do not allow removal of any fields directly, even if it was only accessible in tech preview. Instead, we ask to tombstone them (removal with a comment), see some examples #2256 and #2576
This also means that the field name may not be used again, so we should be certain that we're ok with the removal.
There was a problem hiding this comment.
Thank you for review. That makes sense. I'll update this PR based on your comments, once we finalize the design.
There was a problem hiding this comment.
Instead of directly removing it, I've marked fields as deprecated for now. In next release I'm planning to remove them entirely (by tombstoning as suggested ^^)
openshift-ci
bot
added
size/L
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: flavianmissi The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
ardaguclu
changed the title
|
@ardaguclu: This pull request references API-1844 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn 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.
Actionable comments posted: 16
🤖 Fix all issues with AI agents
In @openapi/generated_openapi/zz_generated.openapi.go:
- Line 9177: The Description string for AWSKMSConfig contains a grammatical
error ("listening this resource type"); update the source that generates this
Description (the AWSKMSConfig description definition) to either "listening to
this resource type" or better: "No controller watches this resource type; we
plan to remove it in the next release." Change the Description for AWSKMSConfig
accordingly in the authoritative source so regenerated openapi code includes the
corrected deprecation notice.
- Around line 16176-16183: The discriminator mapping for the KMS encryption type
is incorrect: in the generated OpenAPI map inside zz_generated.openapi.go the
discriminator entry maps "name" to "Name" but the valid type enum values are
"AWS" and "Manual"; update the discriminator map (the map with key
"discriminator": "type" and "fields-to-discriminateBy") to map "aws" -> "AWS"
and change "name" -> "Manual" so the "name" field discriminates to the Manual
type.
In @openapi/openapi.json:
- Around line 4456-4457: Fix the minor grammar in the deprecation sentence for
the schema "com.github.openshift.api.config.v1.AWSKMSConfig": change "listening
this resource type" to "listening to this resource type" (or "watching this
resource type") in the description string so the deprecation note reads
correctly.
- Around line 4582-4585: The OpenAPI schema for the "name" property documents
that it must be a non-empty string and <=256 chars but lacks enforcement; update
the "name" property in the schema to include validation constraints by adding
"minLength": 1 and "maxLength": 256 to the existing "name" object so the spec
enforces the documented rules.
- Around line 6129-6140: The "conditions" array schema lacks the declared item
limit: add "maxItems": 1 to the "conditions" property (the array that references
"#/definitions/io.k8s.apimachinery.pkg.apis.meta.v1.Condition") so the schema
enforces the description "conditions must not contain more than one entry."
Ensure the "conditions" object keeps its existing "items",
"x-kubernetes-list-map-keys", and "x-kubernetes-list-type" entries and simply
adds the top-level "maxItems": 1 constraint.
- Around line 6094-6102: The OpenAPI schema for the "riskNames" property is
missing the documented validation constraints; update the "riskNames" array
schema (property name: riskNames) to include "maxItems: 500" on the array and
add "maxLength: 256" to the array "items" schema (the string item definition) so
each entry is limited to 256 characters and the list to 500 entries, preserving
the existing "type": "array", "items": { "type": "string" } and
"x-kubernetes-list-type": "set".
- Around line 11644-11655: The schema for the acceptRisks array is missing the
maxItems constraint declared in its description; add "maxItems": 1000 to the
acceptRisks definition (the same object that contains "description", "type",
"items", "x-kubernetes-list-map-keys", and "x-kubernetes-list-type") so the
schema enforces the documented limit of no more than 1000 entries for
acceptRisks.
- Around line 8547-8559: Add JSON Schema length constraints to the "name"
property by adding "minLength": 1 and "maxLength": 80 to enforce the documented
1–80 character limit; correct the grammar in the "aws" description by changing
"listening this resource type" to "listening to this resource type"; and
reconcile the "type" description with the discriminator entries by either
removing "aws" from the discriminator (if AWS support is being removed) or
updating the "type" description to note that "aws" is retained for backward
compatibility—ensure the discriminator and the "type" description are
consistent.
- Around line 5875-5886: The schema for the property conditionalUpdateRisks (in
the OpenAPI definition for com.github.openshift.api.config.v1) documents a
maximum of 500 entries but does not enforce it; add "maxItems: 500" to the
conditionalUpdateRisks array schema (the object containing "type": "array",
"items": { "$ref":
"#/definitions/com.github.openshift.api.config.v1.ConditionalUpdateRisk" }) so
the schema validation matches the description.
In
@payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml:
- Around line 220-227: The CRD's "type" field is inconsistent: its description
says "Manual only" while the enum lists "AWS" and "Manual"; update the "type"
field so schema and docs match—either remove "AWS" from the enum to enforce
Manual-only, or change the description to state both allowed values (e.g.,
"Available provider types are AWS (deprecated) and Manual") and mark AWS as
deprecated if applicable; modify the enum or the description in the "type"
definition to make them consistent (refer to the "type" field under the KMS
provider schema).
- Around line 231-235: The CEL rule currently only requires aws for self.type ==
'AWS' and name for self.type == 'Manual' but doesn't forbid the opposite field;
update the x-kubernetes-validations rule expression to both require the needed
field and forbid the other based on self.type (e.g., for self.type == 'AWS'
ensure has(self.aws) and not has(self.name) and for self.type == 'Manual' ensure
has(self.name) and not has(self.aws), also ensure name != '' and any required
subfields of aws are present); modify the rule under x-kubernetes-validations to
combine these clauses so that aws is forbidden when type == 'Manual' and name is
forbidden when type == 'AWS'.
In
@payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml:
- Around line 220-227: The CRD description for the KMS provider "type" is
misleading—update the description string under the `type` field (the block that
currently reads 'type defines the kind of platform for the KMS provider.
Available provider types are Manual only.') to accurately reflect that `enum`
contains both `AWS` and `Manual`, noting that `AWS` is deprecated/kept for
backward compatibility; reference the `type` field and the enum values `AWS` and
`Manual` and adjust the text to something like "Available provider types are
Manual and AWS (AWS is deprecated/kept for backward compatibility)."
In
@payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml:
- Line 176: Update the deprecation description string for the CRD entry that
currently reads "There is no logic listening this resource type" to correct
grammar; change it to either "There is no logic listening to this resource type"
or "There is no controller watching this resource type" so the Deprecated field
reads clearly and correctly.
- Around line 220-227: The description for the KMS provider "type" is
inconsistent with the enum: it says "Manual only" while the enum lists both AWS
and Manual; update the description in the CRD (the "type" field description) to
accurately reflect the enum (e.g., "Available provider types are Manual and AWS
(AWS is deprecated)" or remove AWS from the enum if AWS is no longer supported)
so the documentation matches the allowed values.
🧹 Nitpick comments (5)
payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
171-176: Tighten/clarify the deprecation wording forkms.awsdocs.Current text (“There is no logic listening this resource type…”) is awkward and can be misread; suggest “no controller/watchers” + (if possible) an explicit release/version target for removal.
config/v1/zz_generated.swagger_doc_generated.go (1)
2328-2332: Swagger doc deprecation message: grammar + separation.
AWSKMSConfig’s""doc string would read better with punctuation and clearer phrasing (“no controller/watchers … planned removal …”). Since this file is generated, prefer fixing the Go type doc comments and regenerating.payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml (3)
176-176: Minor grammar issue in deprecation notice.Consider revising "listening this resource type" to "watching this resource type" or "for this resource". The phrase "this resource type" could also be clarified to explicitly reference "AWS KMS configuration" for better clarity.
231-235: Validation doesn't enforce mutual exclusivity as described.The
namefield description (line 216) states it is "forbidden when type is AWS", but the validation rule only ensures the required fields are present—it doesn't prevent settingnamewhentypeisAWS. A user could set bothawsconfig andnamewhen usingtype: AWS, and validation would pass.If enforcing mutual exclusivity is intended, consider adding explicit checks:
♻️ Suggested stricter validation
x-kubernetes-validations: - - message: aws config is required when kms provider type is AWS; - name is required when kms provider type is Manual - rule: (self.type == 'AWS' && has(self.aws)) || (self.type == - 'Manual' && has(self.name) && self.name != '') + - message: aws config is required when kms provider type is AWS, and name must not be set + rule: "self.type == 'AWS' ? (has(self.aws) && !has(self.name)) : true" + - message: name is required when kms provider type is Manual, and aws must not be set + rule: "self.type == 'Manual' ? (has(self.name) && self.name != '' && !has(self.aws)) : true"Alternatively, if mutual exclusivity is not critical (given AWS is deprecated), update the
namefield description to remove "forbidden when type is AWS" to match actual behavior.
210-219: Add pattern validation to the KMS plugin name field.The
namefield lacks character validation despite being templated into a Unix socket path. Without restrictions, users could provide values containing path separators (/), parent directory references (..), or other characters that could cause socket creation failures or path traversal issues.Other KMS fields in the same struct (AWS region and keyARN) already use pattern validation. Consider adding similar validation here:
Suggested pattern validation
x-kubernetes-validations: - message: name must contain only alphanumeric characters, hyphens, and underscores rule: self.matches('^[a-zA-Z0-9_-]+$')
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge base: Disabled due to data retention organization setting
⛔ Files ignored due to path filters (4)
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlis excluded by!**/zz_generated.featuregated-crd-manifests/**
📒 Files selected for processing (8)
config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlconfig/v1/types_kmsencryption.goconfig/v1/zz_generated.swagger_doc_generated.goopenapi/generated_openapi/zz_generated.openapi.goopenapi/openapi.jsonpayload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- config/v1/types_kmsencryption.go
🔇 Additional comments (9)
config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (4)
8-28: LGTM!Valid endpoint test case correctly validates the External KMS configuration with a properly formatted Unix socket path.
29-59: LGTM!Test cases correctly validate error scenarios:
- Missing
unix:///prefix triggers format error- KMS config with non-KMS encryption type is properly rejected
- Empty KMS config requires the endpoint field
60-79: LGTM!Good coverage for the defaulting behavior - when
endpointis provided withoutmanagementModel, it correctly defaults toExternal.
80-133: LGTM!Comprehensive coverage of edge cases:
- Missing endpoint when
managementModelis specified- Abstract socket patterns (both
@nameand@name/pathforms)- Empty string and whitespace in paths
The minimum length validation of 9 characters correctly ensures at least one character after the
unix:///prefix.payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (2)
231-235: Validation rule doesn't enforce "forbidden" constraint described innamefield.The
namefield description (line 216) states it is "forbidden when type is AWS," but the validation rule only enforces that the required fields are present—it doesn't forbidnamefor AWS orawsfor Manual. This could allow ambiguous configurations.If this is intentional (e.g., for migration flexibility), consider updating the
namefield description to remove "forbidden when type is AWS." Otherwise, consider strengthening the validation:Suggested fix to enforce mutual exclusivity
x-kubernetes-validations: - - message: aws config is required when kms provider type is AWS; - name is required when kms provider type is Manual - rule: (self.type == 'AWS' && has(self.aws)) || (self.type == - 'Manual' && has(self.name) && self.name != '') + - message: aws config is required when kms provider type is AWS, and name must not be set; name is required when kms provider type is Manual, and aws must not be set + rule: (self.type == 'AWS' && has(self.aws) && !has(self.name)) || (self.type == 'Manual' && has(self.name) && self.name != '' && !has(self.aws))
210-219: LGTM on the newnamefield definition.The field constraints (minLength: 1, maxLength: 80) and the documentation explaining the socket path templating are clear and appropriate.
openapi/generated_openapi/zz_generated.openapi.go (1)
16148-16169: Schema additions look correct.The new
namefield is well-documented with clear constraints (1-80 characters, UNIX domain socket path templating). The type field description correctly reflects the transition to "Manual only" provider type.Note: The deprecation notice on line 16166 has the same grammatical issue as flagged earlier ("listening this" → "listening to this").
openapi/openapi.json (2)
8562-8569: LGTM - discriminator maintains backward compatibility.Keeping
awsin the discriminator alongside the newnamefield supports backward compatibility during the deprecation period.
11689-11691: LGTM!The updated description provides clearer documentation of the field's purpose.
payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
Show resolved
Hide resolved
payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
Show resolved
Hide resolved
payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
Show resolved
Hide resolved
payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
Outdated
Show resolved
Hide resolved
ardaguclu
force-pushed
the
kms-api
branch
3 times, most recently
from
6bdb6ac to
94d4f28
Compare
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
config/v1/zz_generated.swagger_doc_generated.go (1)
2328-2343: Swagger doc text is inconsistent (“Manual only”, andnameforbidden for AWS).
typesays “Manual only” while AWS still exists (deprecated), andnameclaims it’s forbidden for AWS without an obvious corresponding validation.Suggested doc wording tweak
@@ - "type": "type defines the kind of platform for the KMS provider. Available provider types are Manual only.", + "type": "type defines the kind of platform for the KMS provider. Available provider types are AWS (deprecated) and Manual.", @@ - "name": "... This field is required when type is Manual, and forbidden when type is AWS. ...", + "name": "... This field is required when type is Manual. It must be omitted when type is AWS. ...",payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (1)
171-236: CRD is missing (or not showing) thekms.namesafe-filename validation, and doesn’t forbid cross-fields.
Given the added negative tests, the CRD should enforce:
kms.namemust not contain/or..kms.namemust be omitted whenkms.type=AWSkms.awsmust be omitted whenkms.type=ManualSuggested CRD schema additions (conceptual; ideally comes from regen)
@@ name: @@ maxLength: 80 minLength: 1 type: string + x-kubernetes-validations: + - message: name must be a safe socket filename (must not contain '/' or '..') + rule: '!self.contains(''/'') && !self.contains(''..'')' @@ x-kubernetes-validations: - message: aws config is required when kms provider type is AWS; name is required when kms provider type is Manual rule: (self.type == 'AWS' && has(self.aws)) || (self.type == 'Manual' && has(self.name) && self.name != '') + - message: name is forbidden when kms provider type is AWS; aws config is forbidden when kms provider type is Manual + rule: (self.type == 'AWS' && !has(self.name)) || (self.type == 'Manual' && !has(self.aws))
🤖 Fix all issues with AI agents
In @config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml:
- Around line 29-50: Update the failing tests so they match the schema’s actual
cross-field validation: either (A) remove expectations that AWS+name or
Manual+aws are forbidden and instead assert success when the required field is
present (e.g., "Should be able to create KMS with AWS provider and valid aws
config" and the Manual case with aws present), or (B) if you introduce a new
forbidden-fields XValidation, add that XValidation to the schema and then keep
the tests but change the expectedError strings to match the combined xValidation
message (replace the exact "name is required when kms provider type is Manual"
expectations for the two Manual missing/empty name tests with the real combined
validation text produced by APIServer.spec.encryption.kms XValidation). Ensure
tests referencing the Manual provider name and AWS config (the tests named
"Should fail to create KMS Manual provider without name", "Should fail to create
KMS Manual provider with empty name", and "Should be able to create KMS with AWS
provider and valid aws config") are updated accordingly and apply the same fix
for the duplicated cases around the later block mentioned.
In @config/v1/types_kmsencryption.go:
- Around line 3-36: KMSConfig currently only requires the correct field per Type
but doesn't forbid the opposite field; update the kubebuilder XValidation rules
on KMSConfig to enforce exclusivity so that when Type == 'AWS' the Name field is
forbidden and AWS must be present, and when Type == 'Manual' the AWS field is
forbidden and Name must be present. Concretely, add XValidation rules
referencing the Type union discriminator and the Name/AWS fields (e.g., on type
KMSConfig: rule="(self.type == 'AWS' => has(self.aws) && !has(self.name)) &&
(self.type == 'Manual' => has(self.name) && !has(self.aws))", with appropriate
messages) so the schema forbids AWS+Name combinations and Manual+aws
combinations.
In
@payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml:
- Around line 220-227: Update the field description for the `type` property (the
YAML `type` key with enum values `AWS` and `Manual`) so it accurately reflects
the enum; replace "Available provider types are Manual only" with a statement
that both `AWS` and `Manual` are valid values and note that `AWS` is deprecated
(or otherwise indicate its deprecated status) so the description matches the
enum.
- Around line 210-219: The CRD YAML's name field is missing the
x-kubernetes-validations that mirror the Go kubebuilder XValidation rule (in
config/v1/types_kmsencryption.go) preventing '/' and '..' in the KMS plugin
name; regenerate the CRD from the Go types so the name property in the CRD
includes the x-kubernetes-validations entry equivalent to the
+kubebuilder:validation:XValidation rule (ensuring the validation message and
rule are preserved), and update the build process to run the CRD generation step
so future edits to the types produce the CRD with the validation.
🧹 Nitpick comments (2)
config/v1/types_kmsencryption.go (1)
63-75: Minor: polish Manual provider godoc for grammar/clarity.
“represents a supported KMS provider is managed…” reads a bit off; worth rephrasing since it’s user-facing API docs.payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)
231-235: Validation rule doesn't enforce mutual exclusivity.The current rule ensures required fields are present for each type, but doesn't prevent setting both
awsandnamewhentype: Manual(ornamewhentype: AWS). The field description statesnameis "forbidden when type is AWS", but the validation doesn't enforce this.Consider strengthening the rule to enforce mutual exclusivity:
Suggested stricter validation
x-kubernetes-validations: - - message: aws config is required when kms provider type is AWS; - name is required when kms provider type is Manual - rule: (self.type == 'AWS' && has(self.aws)) || (self.type == - 'Manual' && has(self.name) && self.name != '') + - message: aws config is required when kms provider type is AWS and name must not be set; name is required when kms provider type is Manual and aws must not be set + rule: (self.type == 'AWS' && has(self.aws) && !has(self.name)) || (self.type == 'Manual' && has(self.name) && self.name != '' && !has(self.aws))Alternatively, if mutual exclusivity is intentionally not enforced (e.g., to allow gradual migration), the field description at line 216 should be updated to remove "forbidden when type is AWS".
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge base: Disabled due to data retention organization setting
⛔ Files ignored due to path filters (4)
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlis excluded by!**/zz_generated.featuregated-crd-manifests/**
📒 Files selected for processing (8)
config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlconfig/v1/types_kmsencryption.goconfig/v1/zz_generated.swagger_doc_generated.goopenapi/generated_openapi/zz_generated.openapi.goopenapi/openapi.jsonpayload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
🔇 Additional comments (12)
openapi/generated_openapi/zz_generated.openapi.go (3)
9174-9180: LGTM!The deprecation notice for
AWSKMSConfigis clear and aligns with the PR objective to phase out AWS-specific KMS configuration in favor of the new Manual provider approach.
16148-16169: LGTM!The new
namefield schema is well-documented with clear constraints (1-80 chars, safe filename rules, conditional requirement based on type). The deprecation notice on theawsfield is consistent with the overall deprecation approach.Since this is a generated file, ensure the source type definitions in
config/v1/types_kmsencryption.gohave the corresponding CEL validation markers to enforce the documented constraints (length, forbidden characters, conditional requirements).
16176-16183: LGTM!The discriminator mapping correctly handles the union type pattern:
awsfield for the deprecated AWS type andnamefield for the new Manual type. This follows OpenShift API conventions for type-discriminated unions.payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml (1)
171-209: Deprecation notice is clear and appropriate.The AWS KMS configuration is properly marked as deprecated with a clear message about planned removal. Retaining the fields while deprecating ensures backward compatibility during the transition period.
openapi/openapi.json (8)
4456-4460: Deprecation notice added for AWSKMSConfig.The deprecation description clearly communicates that this type will be removed in the next release. This aligns with the PR objective to remove AWS-specific KMS configuration.
4575-4587: New AcceptRisk type looks correct.The type definition is straightforward with a required
namefield. The description mentions a 256-character limit; verify that this constraint is enforced via CEL validation or kubebuilder markers in the source Go types, since OpenAPI schema validation alone won't enforce it.
5875-5886: New conditionalUpdateRisks field with map semantics.The field uses
x-kubernetes-list-type: mapkeyed byname, which provides proper merge semantics. The description mentions a 500-entry limit that should be enforced via CEL validation in the source types.
6094-6102: New riskNames field with set semantics.Using
x-kubernetes-list-type: setcorrectly enforces uniqueness. The description mentions 256-character and 500-entry limits that should be enforced via source type validation.
6129-6140: New conditions field with map semantics.The field is correctly defined as a map keyed by
type. The description states "must not contain more than one entry" which is an unusually restrictive limit—verify this is intentional for the design.
8551-8554: New name field for Manual KMS provider.The
namefield description clearly explains the UNIX domain socket path templating and the validation requirements (1-80 chars, safe filename, no '/' or '..'). This aligns with the PR objective of supporting manually managed KMS plugins.Verify that the length and character constraints are enforced via CEL validation in the source Go types.
11644-11655: New acceptRisks field on Update.The field uses map semantics keyed by
namewith a 1000-entry limit mentioned in the description. This provides a mechanism for administrators to accept conditional update risks.
11689-11692: Minor description update for acceptedRisks.The updated description provides clearer examples of what risks might be accepted (Upgradeable=False, missing signature override, non-recommended updates). This is a documentation improvement.
config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
Show resolved
Hide resolved
| // KMSConfig defines the configuration for the KMS instance | ||
| // that will be used with KMSEncryptionProvider encryption | ||
| // +kubebuilder:validation:XValidation:rule="has(self.type) && self.type == 'AWS' ? has(self.aws) : !has(self.aws)",message="aws config is required when kms provider type is AWS, and forbidden otherwise" | ||
| // +kubebuilder:validation:XValidation:rule="(self.type == 'AWS' && has(self.aws)) || (self.type == 'Manual' && has(self.name) && self.name != '')",message="aws config is required when kms provider type is AWS; name is required when kms provider type is Manual" | ||
| // +union | ||
| type KMSConfig struct { | ||
| // type defines the kind of platform for the KMS provider. | ||
| // Available provider types are AWS only. | ||
| // Available provider types are Manual only. | ||
| // | ||
| // +unionDiscriminator | ||
| // +required | ||
| Type KMSProviderType `json:"type"` | ||
|
|
||
| // name specifies the KMS plugin name. | ||
| // This name is templated into the UNIX domain socket path: unix:///var/run/kmsplugin/<name>.sock | ||
| // and is between 1 and 80 characters in length. | ||
| // The KMS plugin must listen at this socket path. | ||
| // This field is required when type is Manual, and forbidden when type is AWS. | ||
| // The name must be a safe socket filename and must not contain '/' or '..'. | ||
| // | ||
| // +kubebuilder:validation:MaxLength=80 | ||
| // +kubebuilder:validation:MinLength=1 | ||
| // +kubebuilder:validation:XValidation:rule="!self.contains('/') && !self.contains('..')",message="name must be a safe socket filename (must not contain '/' or '..')" | ||
| // +optional | ||
| Name string `json:"name,omitempty"` | ||
|
|
||
| // aws defines the key config for using an AWS KMS instance | ||
| // for the encryption. The AWS KMS instance is managed | ||
| // by the user outside the purview of the control plane. | ||
| // Deprecated: There is no logic listening to this resource type, we plan to remove it in next release. | ||
| // | ||
| // +unionMember | ||
| // +optional | ||
| AWS *AWSKMSConfig `json:"aws,omitempty"` | ||
| } |
There was a problem hiding this comment.
Enforce “forbidden” fields (AWS+name, Manual+aws) to match docs/tests.
Right now you only require the correct field; you don’t forbid the other field. If the intent is exclusivity, add an explicit XValidation.
Proposed kubebuilder validation update
// +kubebuilder:validation:XValidation:rule="(self.type == 'AWS' && has(self.aws)) || (self.type == 'Manual' && has(self.name) && self.name != '')",message="aws config is required when kms provider type is AWS; name is required when kms provider type is Manual"
+// +kubebuilder:validation:XValidation:rule="(self.type == 'AWS' && !has(self.name)) || (self.type == 'Manual' && !has(self.aws))",message="name is forbidden when kms provider type is AWS; aws config is forbidden when kms provider type is Manual"
// +union
type KMSConfig struct {
// type defines the kind of platform for the KMS provider.
- // Available provider types are Manual only.
+ // Available provider types are AWS (deprecated) and Manual.🤖 Prompt for AI Agents
In @config/v1/types_kmsencryption.go around lines 3 - 36, KMSConfig currently
only requires the correct field per Type but doesn't forbid the opposite field;
update the kubebuilder XValidation rules on KMSConfig to enforce exclusivity so
that when Type == 'AWS' the Name field is forbidden and AWS must be present, and
when Type == 'Manual' the AWS field is forbidden and Name must be present.
Concretely, add XValidation rules referencing the Type union discriminator and
the Name/AWS fields (e.g., on type KMSConfig: rule="(self.type == 'AWS' =>
has(self.aws) && !has(self.name)) && (self.type == 'Manual' => has(self.name) &&
!has(self.aws))", with appropriate messages) so the schema forbids AWS+Name
combinations and Manual+aws combinations.
payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
Show resolved
Hide resolved
| type: | ||
| description: |- | ||
| type defines the kind of platform for the KMS provider. | ||
| Available provider types are AWS only. | ||
| Available provider types are Manual only. | ||
| enum: | ||
| - AWS | ||
| - Manual | ||
| type: string |
There was a problem hiding this comment.
Description inconsistent with enum values.
The description states "Available provider types are Manual only" but the enum includes both AWS and Manual. This inconsistency may confuse users. Consider updating the description to reflect that AWS is deprecated:
Suggested fix
type:
description: |-
type defines the kind of platform for the KMS provider.
- Available provider types are Manual only.
+ Available provider types are AWS (deprecated) and Manual.
enum:
- AWS
- Manual
type: string📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| type: | |
| description: |- | |
| type defines the kind of platform for the KMS provider. | |
| Available provider types are AWS only. | |
| Available provider types are Manual only. | |
| enum: | |
| - AWS | |
| - Manual | |
| type: string | |
| type: | |
| description: |- | |
| type defines the kind of platform for the KMS provider. | |
| Available provider types are AWS (deprecated) and Manual. | |
| enum: | |
| - AWS | |
| - Manual | |
| type: string |
🤖 Prompt for AI Agents
In
@payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
around lines 220 - 227, Update the field description for the `type` property
(the YAML `type` key with enum values `AWS` and `Manual`) so it accurately
reflects the enum; replace "Available provider types are Manual only" with a
statement that both `AWS` and `Manual` are valid values and note that `AWS` is
deprecated (or otherwise indicate its deprecated status) so the description
matches the enum.
|
@ardaguclu: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
There was a problem hiding this comment.
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)
config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (1)
140-167: Tests will fail: validation rule doesn't enforce mutual exclusivity.The current validation rule is:
(self.type == 'AWS' && has(self.aws)) || (self.type == 'Manual' && has(self.name) && self.name != '')
Lines 140-153: With
type: AWS,awspresent, andname: my-plugin, the first condition(self.type == 'AWS' && has(self.aws))is TRUE, so validation passes. The test expects an error, but won't get one.Lines 154-167: With
type: Manual,name: my-plugin, andawspresent, the second condition is TRUE, so validation passes. The test expects an error, but won't get one.The description states
nameis "forbidden when type is AWS" andawsshould be forbidden when type is Manual, but the validation rule doesn't enforce this mutual exclusivity.🐛 Proposed fix for the validation rule in CRDs and Go types
Update the validation rule to enforce mutual exclusivity:
- rule: (self.type == 'AWS' && has(self.aws)) || (self.type == 'Manual' && has(self.name) && self.name != '') + rule: (self.type == 'AWS' && has(self.aws) && !has(self.name)) || (self.type == 'Manual' && has(self.name) && self.name != '' && !has(self.aws))And update the error message to be more specific:
- message: aws config is required when kms provider type is AWS; name is required when kms provider type is Manual + message: aws config is required when kms provider type is AWS, and name must not be set; name is required when kms provider type is Manual, and aws must not be set
🤖 Fix all issues with AI agents
In @config/v1/zz_generated.swagger_doc_generated.go:
- Around line 2338-2343: The swagger doc for KMSConfig is incorrect: update the
"type" entry in map_KMSConfig (the "type" key in map_KMSConfig) to state that
both Manual and AWS are accepted and that AWS is deprecated (e.g., "type defines
the kind of platform for the KMS provider. Available provider types are Manual
and AWS (AWS is deprecated)."), then regenerate the swagger output so the change
propagates into zz_generated.swagger_doc_generated.go to match the
+kubebuilder:validation:Enum and the deprecation on AWSKMSProvider.
In @openapi/generated_openapi/zz_generated.openapi.go:
- Around line 16176-16183: The discriminator mapping for KMSConfig is wrong: in
the generated map for "fields-to-discriminateBy" change the entry that maps
"name" from "Name" to the actual enum value "Manual" (so the map becomes "name":
"Manual"), ensuring it matches the KMSProviderType enum and the XValidation rule
that ties the name field to type == 'Manual'.
In @openapi/openapi.json:
- Around line 6094-6102: The OpenAPI schema for the riskNames property is
missing the kubebuilder validation constraints; update the riskNames array
schema so the array object includes "maxItems: 500" and the nested "items"
object includes "maxLength: 256" (i.e., add maxItems: 500 to the riskNames
definition and add maxLength: 256 to the items definition for the string) so the
generated API enforces the same constraints as the Go tags referenced by
spec.desiredUpdate.acceptRisks.
- Around line 6129-6140: The OpenAPI "conditions" array schema is missing the
array bounds and has an inaccurate description; add "maxItems": 8 and
"minItems": 1 to the "conditions" property in the OpenAPI schema (the array
under the "conditions" key that references
io.k8s.apimachinery.pkg.apis.meta.v1.Condition) and update the description to
reflect the true validation (e.g., state the list must contain between 1 and 8
unique-type entries). Also update the source comment in
config/v1/types_cluster_version.go that documents the "conditions" field so it
no longer says "must not contain more than one entry" but accurately documents
the allowed 1–8 entries, then regenerate the OpenAPI JSON so the schema and
comment remain consistent.
In
@payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml:
- Around line 236-240: The x-kubernetes-validations rule must enforce mutual
exclusivity between aws and name based on type: update the validation rule for
the CustomNoUpgrade CRD so that when self.type == 'AWS' it requires
has(self.aws) and not has(self.name), and when self.type == 'Manual' it requires
has(self.name) and not has(self.aws) and self.name != ''; also update the
accompanying message to state that name is forbidden when type is AWS and aws is
forbidden when type is Manual to reflect the enforced exclusivity.
🧹 Nitpick comments (2)
config/v1/types_kmsencryption.go (1)
8-9: Comment is misleading - AWS is still a valid enum value.The comment states "Available provider types are Manual only" but line 64 shows
+kubebuilder:validation:Enum=AWS;Manual. While AWS is deprecated, it's still a valid value and the comment could confuse users.✏️ Suggested clarification
// type defines the kind of platform for the KMS provider. -// Available provider types are Manual only. +// Available provider types are AWS (deprecated) and Manual.config/v1/zz_generated.swagger_doc_generated.go (1)
2328-2332: Tighten/standardize the deprecation blurb formatting for AWSKMSConfig docs.Current
""doc string reads like two sentences run together and is missing punctuation (“provider Deprecated: …”). Consider making it a proper sentence and/or puttingDeprecated:on its own sentence for swagger consumers. Since this is generated, please update the source godoc and re-run the generator.Proposed doc string tweak (illustrative; prefer fixing at the source + regen)
- "": "AWSKMSConfig defines the KMS config specific to AWS KMS provider Deprecated: There is no logic listening to this resource type, we plan to remove it in next release.", + "": "AWSKMSConfig defines the KMS config specific to the AWS KMS provider. Deprecated: There is no logic listening to this resource type; it is planned for removal in a future release.",
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge base: Disabled due to data retention organization setting
⛔ Files ignored due to path filters (4)
config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlis excluded by!**/zz_generated.featuregated-crd-manifests/**
📒 Files selected for processing (8)
config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yamlconfig/v1/types_kmsencryption.goconfig/v1/zz_generated.swagger_doc_generated.goopenapi/generated_openapi/zz_generated.openapi.goopenapi/openapi.jsonpayload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
🧰 Additional context used
🧬 Code graph analysis (1)
config/v1/types_kmsencryption.go (1)
config/v1/zz_generated.swagger_doc_generated.go (1)
AWSKMSConfig(2334-2336)
🔇 Additional comments (18)
openapi/generated_openapi/zz_generated.openapi.go (2)
9174-9180: LGTM!The deprecation notice for
AWSKMSConfigis clear and appropriately warns consumers about the planned removal.
16148-16169: LGTM!The new
namefield is well-documented with clear validation rules:
- Socket path templating is clearly explained
- Length constraints (1-80 chars) are specified
- Security-conscious validation (no '/' or '..') prevents path traversal
- Conditional requirements (required for Manual, forbidden for AWS) are explicit
The deprecation notices on the
awsfield appropriately mirror theAWSKMSConfigdeprecation.config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml (4)
8-49: LGTM for Manual provider test cases.These tests correctly validate the Manual provider's
namefield requirements: valid names, missing names, and empty names are all properly covered.
50-84: LGTM for basic AWS provider test cases.The valid AWS config and missing AWS config scenarios are correctly tested.
85-139: LGTM for validation constraint tests.Good coverage for invalid provider types, name length limits, and path traversal prevention (
/and..).
168-213: LGTM for encryption type and AWS format validation tests.The tests correctly validate that KMS config is forbidden with non-KMS encryption types, empty KMS config requires type, and AWS-specific validations for keyARN and region formats.
payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml (2)
176-176: Deprecation note is appropriate.Clear communication that AWS KMS config is deprecated and planned for removal.
210-224: Name field schema looks correct.The
namefield has appropriate constraints: minLength 1, maxLength 80, and validation to prevent path traversal with'/'and'..'.config/v1/types_kmsencryption.go (4)
15-26: Name field definition looks correct.The field has appropriate validation constraints (1-80 chars, no path traversal characters) and clear documentation about socket path templating.
31-35: Deprecation note for AWS field is appropriate.Clear indication that the AWS config path is deprecated.
38-61: AWSKMSConfig type properly marked as deprecated.The struct and its validation rules remain intact for backward compatibility during the deprecation period.
63-75: Provider type enum and constants are well-defined.The enum includes both AWS (deprecated) and Manual types with appropriate constant definitions and documentation.
openapi/openapi.json (6)
4456-4460: LGTM!Clear deprecation notice for
AWSKMSConfigwith appropriate rationale. This aligns with the PR objective to phase out AWS-specific KMS configuration.
8562-8569: LGTM!The discriminator correctly maps the
typefield to the appropriate configuration fields:awsfor AWS type andnamefor Manual type. This enables proper union type validation.
11689-11692: LGTM!The updated description provides helpful examples (Upgradeable=False, missing signature) clarifying what risks may be recorded in
acceptedRisks.
8547-8559: Path-safety validations for thenamefield are properly enforced.The critical constraints mentioned in the description are implemented via kubebuilder markers in the Go type (
config/v1/types_kmsencryption.go):
- Length:
MinLength=1,MaxLength=80- Path traversal prevention: CEL validation rule
!self.contains('/') && !self.contains('..')with explicit error messageThese validations are correctly configured and will be enforced at the Kubernetes API server level, ensuring safe socket path templating for
unix:///var/run/kmsplugin/<name>.sock.
5875-5886: AddmaxItems: 500to the OpenAPI schema to match the Go validation.The Go type in
config/v1/types_cluster_version.go(line 213) enforces this constraint via+kubebuilder:validation:MaxItems=500, but the OpenAPI schema lacks the correspondingmaxItemsproperty. Update the schema to reflect the validation rule already present in the source types.
4575-4587: Verify that validation constraints are enforced.The description states the
namefield "must be a non-empty string and must not exceed 256 characters," but the schema lacks correspondingminLength: 1andmaxLength: 256constraints. If these constraints are enforced via kubebuilder validation markers or CEL validations in the Go types, this is fine. Otherwise, add schema-level validation.
| var map_KMSConfig = map[string]string{ | ||
| "": "KMSConfig defines the configuration for the KMS instance that will be used with KMSEncryptionProvider encryption", | ||
| "type": "type defines the kind of platform for the KMS provider. Available provider types are AWS only.", | ||
| "aws": "aws defines the key config for using an AWS KMS instance for the encryption. The AWS KMS instance is managed by the user outside the purview of the control plane.", | ||
| "type": "type defines the kind of platform for the KMS provider. Available provider types are Manual only.", | ||
| "name": "name specifies the KMS plugin name. This name is templated into the UNIX domain socket path: unix:///var/run/kmsplugin/<name>.sock and is between 1 and 80 characters in length. The KMS plugin must listen at this socket path. This field is required when type is Manual, and forbidden when type is AWS. The name must be a safe socket filename and must not contain '/' or '..'.", | ||
| "aws": "aws defines the key config for using an AWS KMS instance for the encryption. The AWS KMS instance is managed by the user outside the purview of the control plane. Deprecated: There is no logic listening to this resource type, we plan to remove it in next release.", | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify whether KMSConfig.type still permits "AWS" anywhere in the repo-generated artifacts.
set -euo pipefail
echo "=== Searching for KMS type doc string ==="
rg -n --hidden -S 'type defines the kind of platform for the KMS provider' -C2 || echo "No match found"
echo ""
echo "=== Searching for KMSProviderType ==="
rg -n --hidden -S 'KMSProviderType' -C2 || echo "No match found"
echo ""
echo "=== Searching for KMSEncryptionProvider ==="
rg -n --hidden -S 'KMSEncryptionProvider' -C2 || echo "No match found"
echo ""
echo "=== Searching for AWS in KMS context ==="
rg -n --hidden -S '"AWS"' config/v1 -C2 || echo "No match found"Repository: openshift/api
Length of output: 19729
🏁 Script executed:
# Find KMSConfig type definition in source files
fd -e go . --hidden | xargs rg -l 'type KMSConfig struct' || echo "Not found with struct pattern"
# Search for KMSProviderType enum definition
fd -e go . --hidden | xargs rg -l 'KMSProviderType' || echo "KMSProviderType not found"
# Look for type definitions in api package
find . -type f -name "*.go" | xargs rg 'KMSConfig|KMSProvider' -B2 -A5 | head -100Repository: openshift/api
Length of output: 8891
Update type field documentation to reflect AWS deprecation status.
The generated swagger documentation is inconsistent: the type field says "Available provider types are Manual only," but the actual type validation (+kubebuilder:validation:Enum=AWS;Manual in config/v1/types_kmsencryption.go) allows both AWS and Manual. The name and aws field descriptions correctly reference AWS as a valid (though deprecated) option, contradicting the type field doc.
The source type definition marks AWSKMSProvider as deprecated and the XValidation rule explicitly permits type='AWS'. Update the type field doc to indicate AWS is still accepted but deprecated (e.g., "Manual; AWS is deprecated"), then regenerate.
🤖 Prompt for AI Agents
In @config/v1/zz_generated.swagger_doc_generated.go around lines 2338 - 2343,
The swagger doc for KMSConfig is incorrect: update the "type" entry in
map_KMSConfig (the "type" key in map_KMSConfig) to state that both Manual and
AWS are accepted and that AWS is deprecated (e.g., "type defines the kind of
platform for the KMS provider. Available provider types are Manual and AWS (AWS
is deprecated)."), then regenerate the swagger output so the change propagates
into zz_generated.swagger_doc_generated.go to match the
+kubebuilder:validation:Enum and the deprecation on AWSKMSProvider.
| map[string]interface{}{ | ||
| "discriminator": "type", | ||
| "fields-to-discriminateBy": map[string]interface{}{ | ||
| "aws": "AWS", | ||
| "aws": "AWS", | ||
| "name": "Name", | ||
| }, | ||
| }, | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for KMSConfig struct definition in source code
echo "=== Looking for KMSConfig type definition ==="
fd --type f -e go | head -20 | xargs grep -l "type KMSConfig struct" | head -5
echo ""
echo "=== Searching for KMSConfig in go files (excluding generated) ==="
rg -n "type KMSConfig struct" --type go | grep -v zz_generated | head -20
echo ""
echo "=== Searching for provider type enum values ==="
rg -n "type.*ProviderType.*string" --type go | grep -v zz_generated | head -20
echo ""
echo "=== Searching for discriminator-related constants/enums ==="
rg -n "Manual|Name.*ProviderType\|ProviderType.*Manual" --type go | grep -v zz_generated | head -30Repository: openshift/api
Length of output: 4412
🏁 Script executed:
cat -n config/v1/types_kmsencryption.go | head -100Repository: openshift/api
Length of output: 4554
Fix discriminator mapping for KMSConfig name field.
The discriminator maps name to "Name", but the KMSProviderType enum (config/v1/types_kmsencryption.go:64-75) defines only two values: "AWS" and "Manual". The name field is associated with the "Manual" type (confirmed by the XValidation rule on line 5 of the source: self.type == 'Manual' && has(self.name)). The discriminator mapping should use "Manual", not "Name".
Generated code snippet
map[string]interface{}{
"discriminator": "type",
"fields-to-discriminateBy": map[string]interface{}{
"aws": "AWS",
"name": "Name", // Should be "Manual"
},
},
🤖 Prompt for AI Agents
In @openapi/generated_openapi/zz_generated.openapi.go around lines 16176 -
16183, The discriminator mapping for KMSConfig is wrong: in the generated map
for "fields-to-discriminateBy" change the entry that maps "name" from "Name" to
the actual enum value "Manual" (so the map becomes "name": "Manual"), ensuring
it matches the KMSProviderType enum and the XValidation rule that ties the name
field to type == 'Manual'.
| x-kubernetes-validations: | ||
| - message: aws config is required when kms provider type is AWS, | ||
| and forbidden otherwise | ||
| rule: 'has(self.type) && self.type == ''AWS'' ? has(self.aws) | ||
| : !has(self.aws)' | ||
| - message: aws config is required when kms provider type is AWS; | ||
| name is required when kms provider type is Manual | ||
| rule: (self.type == 'AWS' && has(self.aws)) || (self.type == | ||
| 'Manual' && has(self.name) && self.name != '') |
There was a problem hiding this comment.
Validation rule needs mutual exclusivity enforcement.
As noted in the test file review, this rule doesn't prevent setting both name and aws fields simultaneously, which contradicts the documented behavior that name is "forbidden when type is AWS."
🤖 Prompt for AI Agents
In
@payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
around lines 236 - 240, The x-kubernetes-validations rule must enforce mutual
exclusivity between aws and name based on type: update the validation rule for
the CustomNoUpgrade CRD so that when self.type == 'AWS' it requires
has(self.aws) and not has(self.name), and when self.type == 'Manual' it requires
has(self.name) and not has(self.aws) and self.name != ''; also update the
accompanying message to state that name is forbidden when type is AWS and aws is
forbidden when type is Manual to reflect the enforced exclusivity.
|
@ardaguclu: This pull request references API-1844 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn 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. |
|
@ardaguclu: This pull request references API-1844 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn 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. |
5 participants
KMSConfigis gated behindKMSEncryptionProviderfeature gate which is in tech preview. This PR tries to add the changes proposed in openshift/enhancements#1900 EP.This PR;
AWSKMSConfigfield andAWSKMSProviderType, since they are not used by anywhere already (we'll tombstone them in next release)ManualKMSProviderType andNamefield for manually managed KMS pluginsNote: We'll have to backport these changes into 4.21.