Skip to content

Conversation

@ardaguclu
Copy link
Member

@ardaguclu ardaguclu commented Dec 12, 2025

KMSConfig is gated behind KMSEncryptionProvider feature gate which is in tech preview. This PR tries to add the changes proposed in openshift/enhancements#1900 EP.

This PR;

  • deprecates AWSKMSConfig field and AWS KMSProviderType, since they are not used by anywhere already (we'll tombstone them in next release)
  • adds new Manual KMSProviderType and Name field for manually managed KMS plugins

Note: We'll have to backport these changes into 4.21.

@openshift-ci-robot
Copy link

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

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

This repository is configured in: LGTM mode

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Dec 12, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 12, 2025

@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.

Details

In response to this:

KMSConfig is gated behind KMSEncryptionProvider feature gate which is currently in tech preview. However, currently there isn't any controller listening KMSConfig and KMSEncryptionProvider. So that gives us an opportunity to change the API fields in a breaking way, according to the newest updates in this feature.

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.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Dec 12, 2025

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

@ardaguclu
Copy link
Member Author

/hold

@coderabbitai
Copy link

coderabbitai bot commented Dec 12, 2025

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

📥 Commits

Reviewing files that changed from the base of the PR and between 10035da and a1f3c29.

⛔ Files ignored due to path filters (4)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml is excluded by !**/zz_generated.featuregated-crd-manifests/**
📒 Files selected for processing (8)
  • config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • config/v1/types_kmsencryption.go
  • config/v1/zz_generated.swagger_doc_generated.go
  • openapi/generated_openapi/zz_generated.openapi.go
  • openapi/openapi.json
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
 ___________________________________________________________________________________________________________
< Childhood dream: become a code reviewer. Adult reality: became a code reviewer. Childhood dream achieved. >
 -----------------------------------------------------------------------------------------------------------
  \
   \   \
        \ /\
        ( )
      .( o ).
📝 Walkthrough

Walkthrough

The PR introduces Manual/External KMS support alongside deprecated AWS KMS. It adds a name field (1–80 chars, safe-filename rules) for Manual provider configs and an endpoint field (unix:///socket path, min 9/max 120) for External KMS plugins, updates validation and discriminator rules to require aws for AWS type or name for Manual type, and marks AWS-related types/config as deprecated. CRD manifests, OpenAPI/Swagger schemas, generated code, and tests were updated to reflect these schema and validation changes.

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title 'API-1844: Update KMSConfig to allow manualy managed kms plugins' clearly describes the main change: extending KMSConfig to support manually managed KMS plugins in addition to existing AWS-based options.
Description check ✅ Passed The pull request description clearly relates to the changeset, explaining the deprecation of AWS KMS fields and addition of Manual KMS provider support.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings

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

@openshift-ci openshift-ci bot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Dec 12, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 12, 2025

@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.

Details

In response to this:

KMSConfig is gated behind KMSEncryptionProvider feature gate which is in tech preview. However, currently there isn't any controller listening KMSConfig and KMSEncryptionProvider. So that gives us an opportunity to change the API fields in a breaking way, according to the newest updates in this feature.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 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 after unix:///, 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-validations rule at lines 180-182 checks self.startsWith('unix:///'), which is already enforced by the pattern at line 178. The pattern ^unix:///(@[^/\s]+|[^@\s].*)$ ensures the string starts with unix:/// through the ^ anchor.

Consider removing the redundant startsWith validation 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 pattern and x-kubernetes-validations.startsWith creates redundant checks. The pattern already enforces the unix:/// 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/socket or unix:///@abstractsocket), but this validation is not enforced by the schema itself (no pattern or format constraint). 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

📥 Commits

Reviewing files that changed from the base of the PR and between c2a41ea and 3f54cfe.

📒 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.go
  • config/v1/zz_generated.swagger_doc_generated.go
  • config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • config/v1/types_kmsencryption.go
  • 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-CustomNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • openapi/openapi.json
  • openapi/generated_openapi/zz_generated.openapi.go
  • payload-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 new KMSConfig shape (shallow-copy-safe).

**out = **in is the expected deepcopy-gen pattern here, and KMSConfig.DeepCopyInto being *out = *in indicates 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 making endpoint required 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 startsWith check alongside the comprehensive pattern validation.

config/v1/types_kmsencryption.go (2)

6-13: LGTM - Type field properly configured.

The Type field correctly defaults to External and is marked optional, allowing the default behavior to take effect when unspecified. The enum restriction to External only is appropriate for this migration.


27-34: LGTM - Clean enum definition.

The KMSProviderType enum restriction and ExternalKMSProvider constant 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.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 12, 2025

@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.

Details

In response to this:

KMSConfig is gated behind KMSEncryptionProvider feature gate which is in tech preview. However, currently there isn't any controller listening KMSConfig and KMSEncryptionProvider. So that gives us an opportunity to change the API fields in a breaking way, according to the newest updates in this feature (AWS related kms configurations are obsolete, since we won't support it)

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.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 12, 2025

@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.

Details

In response to this:

KMSConfig is gated behind KMSEncryptionProvider feature gate which is in tech preview. However, currently there isn't any controller listening KMSConfig and KMSEncryptionProvider. So that gives us an opportunity to change the API fields in a breaking way, according to the newest updates in this feature (AWS related kms configurations are obsolete, since we won't support it internally)

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 4

♻️ Duplicate comments (2)
openapi/generated_openapi/zz_generated.openapi.go (1)

15140-15146: type field still missing Enum and Default

The previously flagged issue persists: the type field lacks Enum: []interface{}{"External"} and Default: "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 required endpoint (and tighten validation).
endpoint is required (Line 7973-7975) but defaults to "" (Line 7980), which is not a valid unix socket endpoint. Also, type reads 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

📥 Commits

Reviewing files that changed from the base of the PR and between 3f54cfe and ded0d94.

📒 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.go
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • config/v1/zz_generated.swagger_doc_generated.go
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • openapi/generated_openapi/zz_generated.openapi.go
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • config/v1/types_kmsencryption.go
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • openapi/openapi.json
🔇 Additional comments (5)
config/v1/zz_generated.deepcopy.go (1)

43-50: Confirm shallow-copy semantics for KMSConfig are safe here

**out = **in performs a value copy of the KMSConfig struct. This is fine if KMSConfig only 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 current KMSConfig shape matches this assumption.

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

170-195: endpoint.minLength: 9 likely rejects valid unix:///a endpoints; regex also allows whitespace

If unix:///a should be valid, minLength should be 8 (not 9). 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; \s is properly supported in Kubernetes CEL regex (which uses RE2)

Kubernetes' CEL matches() function uses the RE2 regex dialect via cel-go, which fully supports \s as 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.
Restricting KMSProviderType to External and using ExternalKMSProvider aligns with the CRD defaulting/enum.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Dec 12, 2025

@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.

Details

In response to this:

KMSConfig is gated behind KMSEncryptionProvider feature gate which is in tech preview. However, currently there isn't any controller listening KMSConfig and KMSEncryptionProvider. So that gives us an opportunity to change the API fields in a breaking way, according to the newest updates in this feature (AWS related kms configurations are obsolete, since we won't support it internally)

Note: We'll have to backport these changes into 4.21.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 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 enforce type constraints (enum/default) and may under-validate endpoint

type’s description says it defaults to and only allows "External", but the schema doesn’t set Enum / Default, so clients won’t get validation from OpenAPI (and may accept invalid values). Also consider encoding the unix-socket constraints for endpoint as Pattern/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 \s escape 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 omitempty tag on the required field is intentional per project linting requirements.

openapi/openapi.json (2)

7973-7986: Remove invalid empty-string default for required endpoint (and consider constraining type).
endpoint is required (Line 7973-7975) but has "default": "" (Line 7980), which contradicts the described unix socket format and can generate invalid defaults in clients. Also, type claims 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 required policyType to ""; enforce allowed values.
The description says policyType is 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

📥 Commits

Reviewing files that changed from the base of the PR and between ded0d94 and fb3a92d.

📒 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.yaml
  • openapi/generated_openapi/zz_generated.openapi.go
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • config/v1/zz_generated.swagger_doc_generated.go
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • config/v1/zz_generated.deepcopy.go
  • config/v1/types_kmsencryption.go
  • openapi/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. The KMSConfig struct contains only value types (Type as KMSProviderType, a string alias, and Endpoint as string), making the shallow copy **out = **in safe.

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

2194-2202: KMSConfig SwaggerDoc looks consistent with the new External+endpoint model
Docs clearly communicate type=External and 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 unless spec.encryption.type=KMS, and endpoint is required
These cases validate the key guardrail and the required-ness of endpoint.


60-110: Verify defaulting + error-message stability in the test harness
If expectedError requires exact matching, messages like spec.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 allows unix:///@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 + required endpoint with format validation
The required field, enum restriction, defaulting to External, 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 omitempty tag 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 AWSKMSProvider to ExternalKMSProvider with 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.

@ardaguclu
Copy link
Member Author

verify-crd-schema and verify-crdify failures are valid. Because we are removing aws related fields.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

♻️ 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: Align kms.endpoint CEL regex across all CRD variants (featuregated/generated/payload).
This manifest’s rule: 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 -u
config/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/enum External, 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 invalid policyType default "" 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 endpoint containing \t/\n if 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

📥 Commits

Reviewing files that changed from the base of the PR and between fb3a92d and e5ef450.

📒 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.yaml
  • config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • config/v1/zz_generated.deepcopy.go
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • config/v1/types_kmsencryption.go
  • openapi/openapi.json
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • config/v1/zz_generated.swagger_doc_generated.go
  • openapi/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 describe type=External and the unix socket endpoint formats. Since this is generated, just ensure the source-of-truth type comments/validation in config/v1/types_kmsencryption.go match 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 \s regex 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:

  1. Filesystem paths cannot contain newlines (kernel restriction), and tabs in socket paths are extraordinarily rare in practice.
  2. The suggested \s fix is problematic: it would match newlines, which could break YAML multiline string parsing that occurs before validation.
  3. 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.
  4. 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: Constrain KMSConfig.type to 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 with enum (and optionally default) so generated clients/validation can’t accept arbitrary values. Also, endpoint is required but shown without any pattern/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"
         }
       }

@ardaguclu
Copy link
Member Author

/cc @flavianmissi
I'd like to hear your opinions. This aligns with the API definitions in your EP (External, Internal). Also we won't need to generate unix domain socket anymore. This will be our unique identifier.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

♻️ Duplicate comments (3)
openapi/generated_openapi/zz_generated.openapi.go (1)

15140-15146: [Duplicate] OpenAPI schema still missing Enum and Default for type field

The generated schema lacks Enum: ["External"] and Default: "External" despite the description stating "defaults to External". This is the same issue flagged in the previous review.

The source markers (+kubebuilder:default=External and +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: Tighten endpoint CEL regex to match documented unix:///path / unix:///@name more precisely. The current pattern (a) allows unix:////... 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 values

This 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 for APIServerEncryption.KMS (avoid **out = **in). The current code is equivalent today, but it’s easy to accidentally lose deep-copy semantics if KMSConfig later 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 state endpoint is required; CRD/schema typically uses “unix domain socket” and makes endpoint required + 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 for endpoint format

The description specifies that the endpoint must follow the format "unix:///path/to/socket" or "unix:///@abstractname", but the schema lacks a Pattern field 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 Pattern field.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

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

📥 Commits

Reviewing files that changed from the base of the PR and between e5ef450 and 49b5e72.

📒 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.go
  • config/v1/types_kmsencryption.go
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • openapi/openapi.json
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • openapi/generated_openapi/zz_generated.openapi.go
  • config/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.
endpoint is required and validated with ^unix:///(@[^/ ]+|[^@ ][^ ]*)$, which appears to cover unix:///path and unix:///@abstractname as 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 new kms.endpoint + External-only provider model. Please keep this file regenerated from config/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: endpoint required + 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).

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

♻️ 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 (typemanagementModel, awsendpoint), but the validation gaps identified in previous reviews persist:

  1. managementModel (Lines 15140-15146): Description states "Valid values are "External"" but lacks:

    • Enum: []interface{}{"External"} to enforce the single valid value
    • Default: "External" to provide the default
  2. endpoint (Lines 15147-15153): Description specifies unix socket format patterns but lacks:

    • Pattern: "^unix:///.*$|^unix:///@.*$" to enforce the format

Since this is a generated file, add the missing kubebuilder markers to the source type definition in config/v1/types_kmsencryption.go:

  • +kubebuilder:validation:Enum=External on the managementModel field
  • +kubebuilder:default=External on the managementModel field
  • +kubebuilder:validation:Pattern=^unix:///.*$|^unix:///@.*$ on the endpoint field

Then 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: missing minLength, maxLength, and pattern constraints
  • managementModel: missing enum and default values

Ensure 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 solid

The unix-domain-socket endpoint validation and managementModel enum/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 align maxLength with 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

📥 Commits

Reviewing files that changed from the base of the PR and between 7c879fc and ab46a2a.

📒 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.yaml
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • config/v1/zz_generated.swagger_doc_generated.go
  • config/v1/types_kmsencryption.go
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • config/v1/zz_generated.deepcopy.go
  • openapi/generated_openapi/zz_generated.openapi.go
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • openapi/openapi.json
🔇 Additional comments (10)
config/v1/zz_generated.deepcopy.go (1)

42-51: DeepCopy change for KMSConfig is correct

Using new(KMSConfig) plus **out = **in is appropriate now that KMSConfig only 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 + required Endpoint with the unix‑socket regex, length bounds, default, and docs all line up with the CRDs and tests. The omitempty on 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

endpoint and managementModel definitions (including requiredness, defaults, and CEL regex) are in sync with KMSConfig and 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 CRDs

The kms endpoint and managementModel fields, 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 semantics

The 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 sets

The kms block (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 model

The updated map_KMSConfig entries correctly describe the new managementModel and endpoint fields and match the CRD semantics (external plugin via unix:///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 External and 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 endpoint required (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.

@ardaguclu
Copy link
Member Author

@flavianmissi I've excluded abstract Linux paths from the validations (as we agreed upon). Could you PTAL?.

Copy link
Member

@flavianmissi flavianmissi left a comment

Choose a reason for hiding this comment

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

Looks great!

/lgtm

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

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

@ardaguclu
Copy link
Member Author

/test e2e-aws-ovn
/test e2e-upgrade-out-of-change

@JoelSpeed
Copy link
Contributor

/lgtm cancel
/hold

@ardaguclu @flavianmissi While I appreciate the team review and LGTM, please don't /lgtm on this repo until an API approver has had a pass. We are trying to avoid needless CI cycles so our E2Es don't run until the lgtm label is added, odds are that an API reviewer will ask for some changes so these E2E cycles are not going to help for the moment.

Will get you a reviewer assigned

@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Dec 16, 2025
@ardaguclu
Copy link
Member Author

ardaguclu commented Dec 16, 2025

/lgtm cancel /hold

@ardaguclu @flavianmissi While I appreciate the team review and LGTM, please don't /lgtm on this repo until an API approver has had a pass. We are trying to avoid needless CI cycles so our E2Es don't run until the lgtm label is added, odds are that an API reviewer will ask for some changes so these E2E cycles are not going to help for the moment.

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).

@JoelSpeed
Copy link
Contributor

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"`
Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thank you for review. That makes sense. I'll update this PR based on your comments, once we finalize the design.

Copy link
Member Author

Choose a reason for hiding this comment

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

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 openshift-ci bot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Jan 12, 2026
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 12, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: flavianmissi
Once this PR has been reviewed and has the lgtm label, please ask for approval from joelspeed. For more information see the Code Review Process.

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

Details Needs approval from an approver in each of these files:

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

@ardaguclu ardaguclu changed the title API-1844: Update KMSConfig to support all external kms plugins API-1844: Update KMSConfig to allow manualy managed kms plugins Jan 12, 2026
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 12, 2026

@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.

Details

In response to this:

KMSConfig is gated behind KMSEncryptionProvider feature gate which is in tech preview. This PR tries to add the changes proposed in openshift/enhancements#1900 EP.

Note: We'll have to backport these changes into 4.21.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 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 for kms.aws docs.

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 name field 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 setting name when type is AWS. A user could set both aws config and name when using type: 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 name field description to remove "forbidden when type is AWS" to match actual behavior.


210-219: Add pattern validation to the KMS plugin name field.

The name field 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

📥 Commits

Reviewing files that changed from the base of the PR and between ab46a2a and edde5a2.

⛔ Files ignored due to path filters (4)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml is excluded by !**/zz_generated.featuregated-crd-manifests/**
📒 Files selected for processing (8)
  • config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • config/v1/types_kmsencryption.go
  • config/v1/zz_generated.swagger_doc_generated.go
  • openapi/generated_openapi/zz_generated.openapi.go
  • openapi/openapi.json
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • payload-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 endpoint is provided without managementModel, it correctly defaults to External.


80-133: LGTM!

Comprehensive coverage of edge cases:

  • Missing endpoint when managementModel is specified
  • Abstract socket patterns (both @name and @name/path forms)
  • 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 in name field.

The name field 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 forbid name for AWS or aws for Manual. This could allow ambiguous configurations.

If this is intentional (e.g., for migration flexibility), consider updating the name field 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 new name field 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 name field 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 aws in the discriminator alongside the new name field supports backward compatibility during the deprecation period.


11689-11691: LGTM!

The updated description provides clearer documentation of the field's purpose.

@ardaguclu ardaguclu force-pushed the kms-api branch 3 times, most recently from 6bdb6ac to 94d4f28 Compare January 12, 2026 07:53
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 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”, and name forbidden for AWS).
type says “Manual only” while AWS still exists (deprecated), and name claims 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) the kms.name safe-filename validation, and doesn’t forbid cross-fields.
Given the added negative tests, the CRD should enforce:

  • kms.name must not contain / or ..
  • kms.name must be omitted when kms.type=AWS
  • kms.aws must be omitted when kms.type=Manual
Suggested 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 aws and name when type: Manual (or name when type: AWS). The field description states name is "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

📥 Commits

Reviewing files that changed from the base of the PR and between edde5a2 and 94d4f28.

⛔ Files ignored due to path filters (4)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml is excluded by !**/zz_generated.featuregated-crd-manifests/**
📒 Files selected for processing (8)
  • config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • config/v1/types_kmsencryption.go
  • config/v1/zz_generated.swagger_doc_generated.go
  • openapi/generated_openapi/zz_generated.openapi.go
  • openapi/openapi.json
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml
  • payload-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 AWSKMSConfig is 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 name field schema is well-documented with clear constraints (1-80 chars, safe filename rules, conditional requirement based on type). The deprecation notice on the aws field is consistent with the overall deprecation approach.

Since this is a generated file, ensure the source type definitions in config/v1/types_kmsencryption.go have 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: aws field for the deprecated AWS type and name field 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 name field. 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: map keyed by name, 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: set correctly 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 name field 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 name with 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.

Comment on lines 3 to 36
// 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"`
}
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

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.

Comment on lines 220 to 232
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
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

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.

Suggested change
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.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 12, 2026

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

Test name Commit Details Required Rerun command
ci/prow/e2e-aws-serial-techpreview-1of2 ab46a2a link true /test e2e-aws-serial-techpreview-1of2
ci/prow/e2e-aws-serial-techpreview-2of2 ab46a2a link true /test e2e-aws-serial-techpreview-2of2
ci/prow/verify 94d4f28 link true /test verify

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 6

Caution

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

⚠️ Outside diff range comments (1)
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, aws present, and name: 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, and aws present, the second condition is TRUE, so validation passes. The test expects an error, but won't get one.

The description states name is "forbidden when type is AWS" and aws should 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 putting Deprecated: 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

📥 Commits

Reviewing files that changed from the base of the PR and between 94d4f28 and 10035da.

⛔ Files ignored due to path filters (4)
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1/zz_generated.featuregated-crd-manifests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml is excluded by !**/zz_generated.featuregated-crd-manifests/**
📒 Files selected for processing (8)
  • config/v1/tests/apiservers.config.openshift.io/KMSEncryptionProvider.yaml
  • config/v1/types_kmsencryption.go
  • config/v1/zz_generated.swagger_doc_generated.go
  • openapi/generated_openapi/zz_generated.openapi.go
  • openapi/openapi.json
  • payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml
  • 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
🧬 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 AWSKMSConfig is clear and appropriately warns consumers about the planned removal.


16148-16169: LGTM!

The new name field 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 aws field appropriately mirror the AWSKMSConfig deprecation.

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 name field 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 name field 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 AWSKMSConfig with appropriate rationale. This aligns with the PR objective to phase out AWS-specific KMS configuration.


8562-8569: LGTM!

The discriminator correctly maps the type field to the appropriate configuration fields: aws for AWS type and name for 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 the name field 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 message

These 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: Add maxItems: 500 to 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 corresponding maxItems property. 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 name field "must be a non-empty string and must not exceed 256 characters," but the schema lacks corresponding minLength: 1 and maxLength: 256 constraints. If these constraints are enforced via kubebuilder validation markers or CEL validations in the Go types, this is fine. Otherwise, add schema-level validation.

Comment on lines 2338 to 2343
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.",
}
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 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 -100

Repository: 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.

Comment on lines 236 to +240
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 != '')
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🔴 Critical

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.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 12, 2026

@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.

Details

In response to this:

KMSConfig is gated behind KMSEncryptionProvider feature gate which is in tech preview. This PR tries to add the changes proposed in openshift/enhancements#1900 EP.

This PR;

  • deprecates AWSKMSConfig field and AWS KMSProviderType, since they are not used by anywhere already (we'll tombstone them in next release)
  • adds new Manual KMSProviderType and Name field for manually managed KMS plugins

Note: We'll have to backport these changes into 4.21.

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.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 12, 2026

@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.

Details

In response to this:

KMSConfig is gated behind KMSEncryptionProvider feature gate which is in tech preview. This PR tries to add the changes proposed in openshift/enhancements#1900 EP.

This PR;

  • deprecates AWSKMSConfig field and AWS KMSProviderType, since they are not used by anywhere already (we'll tombstone them in next release)
  • adds new Manual KMSProviderType and Name field for manually managed KMS plugins

Note: We'll have to backport these changes into 4.21.

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.

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

Labels

do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants