CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers #2086

ardaguclu · 2026-01-23T07:39:37Z

This PR adds the implementation proposed in openshift/enhancements#1900.

This PR introduces KMS as a new mode in encryption controllers to be functioning along side with the other modes. Basically, the idea is to track the KMS configuration to detect any configuration changes. So that key_controller can create new Secret to initiate migration. KMS Secret will not contain any confidential data. It will simply store the KMS configuration.

For Tech Preview v1, we will only support static unix domain socket (i.e. unix:///var/run/kmsplugin/kms.sock). Consequently, in this version, we don't support KMS -> KMS migrations.

Ref: Previous attemps:

Notes:

The changes here will be backported to 4.21
Substantial portion of the changed lines are unit and integration tests.

openshift-ci-robot · 2026-01-23T07:39:42Z

@ardaguclu: This pull request references CNTRLPLANE-2241 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:

This PR adds the implementation proposed in openshift/enhancements#1900.

This PR introduces KMS as a new mode in encryption controllers to be functioning along side with the other modes. Basically, the idea is to track the KMS configuration to detect any configuration changes. So that key_controller can create new Secret to initiate migration. KMS Secret will not contain any confidential data. It will simply store the KMS configuration.

For Tech Preview v1, we will only support static unix domain socket (i.e. unix:///var/run/kmsplugin/kms.sock). Consequently, in this version, we don't support KMS -> KMS migrations.

Ref: Previous attemps:

NO-JIRA: Introduce KMS encryption mode into encryption controllers #2045

API-1844: KMS Encryption Provider #1876

Notes:

The changes here will be backported to 4.21

Most of the changes are obsessively added unit tests

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 · 2026-01-23T07:42:21Z

@ardaguclu: This pull request references CNTRLPLANE-2241 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:

This PR adds the implementation proposed in openshift/enhancements#1900.

This PR introduces KMS as a new mode in encryption controllers to be functioning along side with the other modes. Basically, the idea is to track the KMS configuration to detect any configuration changes. So that key_controller can create new Secret to initiate migration. KMS Secret will not contain any confidential data. It will simply store the KMS configuration.

For Tech Preview v1, we will only support static unix domain socket (i.e. unix:///var/run/kmsplugin/kms.sock). Consequently, in this version, we don't support KMS -> KMS migrations.

Ref: Previous attemps:

NO-JIRA: Introduce KMS encryption mode into encryption controllers #2045

API-1844: KMS Encryption Provider #1876

Notes:

The changes here will be backported to 4.21

Substantial portion of the changed lines are unit tests.

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 · 2026-01-23T08:51:01Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ardaguclu
Once this PR has been reviewed and has the lgtm label, please assign dgrisonnet for approval. 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:

pkg/operator/encryption/OWNERS
test/e2e-encryption/OWNERS

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

openshift-ci-robot · 2026-01-23T08:56:35Z

@ardaguclu: This pull request references CNTRLPLANE-2241 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:

This PR adds the implementation proposed in openshift/enhancements#1900.

This PR introduces KMS as a new mode in encryption controllers to be functioning along side with the other modes. Basically, the idea is to track the KMS configuration to detect any configuration changes. So that key_controller can create new Secret to initiate migration. KMS Secret will not contain any confidential data. It will simply store the KMS configuration.

For Tech Preview v1, we will only support static unix domain socket (i.e. unix:///var/run/kmsplugin/kms.sock). Consequently, in this version, we don't support KMS -> KMS migrations.

Ref: Previous attemps:

NO-JIRA: Introduce KMS encryption mode into encryption controllers #2045

API-1844: KMS Encryption Provider #1876

Notes:

The changes here will be backported to 4.21

Substantial portion of the changed lines are unit and integration tests.

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

ardaguclu · 2026-01-23T09:24:27Z

Fake imports;

ardaguclu · 2026-01-27T07:43:02Z

/hold
These PRs are prerequisite of this;

OCPBUGS-68343: Bump openshift/api to get new KMS FG #2091 -- conceptually be based on the new feature gate (Rebased)
NO-JIRA: Enable test-e2e-encryption #2087 -- to be able to run integration tests (Rebased)

ardaguclu · 2026-01-27T15:54:14Z

/uncc @dgrisonnet
/cc @benluddy @bertinatto @p0lyn0mial

p0lyn0mial · 2026-02-05T11:11:13Z

I believe that finally this is ready for review

ok, thanks, i will start reviewing soon.

p0lyn0mial

I did a quick first pass.
Looked mostly at key_controller.go.

I posted my question / observation below. Let me know what you think.

p0lyn0mial · 2026-02-05T13:51:48Z

pkg/operator/encryption/secrets/secrets.go

 	}

+	if len(ks.KMSConfig) > 0 {
+		s.Annotations[EncryptionSecretKMSConfig] = string(ks.KMSConfig)


Since v1 assumes the KMS configuration is always the same and static, and we don’t know what future v2 will look like.

I’m wondering if we could slightly simplify the code by always putting the well-known configuration in the annotation when the current mode is KMS. This could simplify the code and potential places we would have to change.

I'll investigate the possible implications tomorrow and get back to you. I think it would be simpler as you said.

Initially I tried to adopt generic approach that would work also for v2 (except the API changes). But I think starting simple by dropping the unsupported parts in v1 alleviates both of us cognitive load.

Thus, generic KMSConfig is dropped, instead default endpoint is embedded. There isn't KMSConfig comparison anymore, because we don't support this already.

p0lyn0mial · 2026-02-05T15:57:52Z

pkg/operator/encryption/controllers/key_controller.go

+	if currentMode == state.KMS {
+		// We are here because Encryption Mode is not changed
+		secret := crypto.ModeToNewKeyFunc[state.KMS](kmsConfig)
+		if latestKey.Key.Secret != base64.StdEncoding.EncodeToString(secret) {


i'm not sure that all changes/updates to a kms config should trigger a new key generation. rolling out a new key is expensive in terms of required shutdowns. also changing a timeout seems like an update that should not require a new key. something we need to figure out for v2.

I completely agree with you. From the perspective of this line, it doesn't matter what secret includes. This line in any case need to compare the secret to detect new key or not.

https://github.com/openshift/library-go/pull/2086/changes#diff-de68f84fb611b486200c440adbdd1997edb7ab5ffbc520e485b39f73b18d339eR296-R304 this is where we decide which data should trigger new key or not (by forming the source of the secret)

However, in v1, we don't support kms configurational changes. We always embed the same well-known endpoint. In order to keep the simplicity, I've removed secret comparison for KMS. Latest version of this PR embeds well known endpoint and keeps tracks of it.

ardaguclu · 2026-02-06T06:43:51Z

pkg/operator/encryption/controllers/key_controller.go


 func (c *keyController) generateKeySecret(keyID uint64, currentMode state.Mode, internalReason, externalReason string) (*corev1.Secret, error) {
-	bs := crypto.ModeToNewKeyFunc[currentMode]()
+	kmsConfig := []byte(kms.DefaultEndpoint)


This should include the selective set of kms fields from APIServer config that will trigger new key. For now it is statically set.

ardaguclu · 2026-02-06T06:44:44Z

pkg/operator/encryption/crypto/keys.go

+
+func NewKMSKey(externalKey []byte) []byte {
+	// Used as fixed-length identifier in EncryptionConfiguration provider names.
+	// Example: kms-secrets-1-a7K9mJ2xH4nQ8pL5vR3wTg==


We can use hexadecimal instead base64

ardaguclu · 2026-02-06T06:45:21Z

pkg/operator/encryption/encryptionconfig/config.go

 				},
 			})
+		case state.KMS:
+			kmsConfig := string(key.KMSConfig)


In v1, key.KMSConfig equals to well known endpoint.

p0lyn0mial

thanks, left a few additional comments. ptal when you have time.

p0lyn0mial · 2026-02-06T08:16:44Z

pkg/operator/encryption/state/types.go

 	// the user via unsupportConfigOverrides.encryption.reason triggered this key.
 	ExternalReason string
+	// Encoded KMSConfig that stores the KMS related fields
+	KMSConfig []byte


nit could this be renamed to KMSConfiguration ?

p0lyn0mial · 2026-02-06T08:17:36Z

pkg/operator/encryption/state/types.go

 	// the user via unsupportConfigOverrides.encryption.reason triggered this key.
 	ExternalReason string
+	// Encoded KMSConfig that stores the KMS related fields
+	KMSConfig []byte


could KMSConfiguration be a struct ? why []bytes ?

could KMSConfiguration be:

KMSConfiguration *apiserverconfigv1.KMSConfiguration

?

I tried to answer in #2086 (comment). KMSConfiguration refers to plugin specific configuration rather than apiserverconfigv1.KMSConfiguration

I store as bytes array to keep the generality. Because each plugin type will have their own specific fields.

p0lyn0mial · 2026-02-06T08:18:23Z

pkg/operator/encryption/controllers/key_controller.go

 		ExternalReason: externalReason,
 	}
+	if currentMode == state.KMS {
+		ks.KMSConfig = kmsConfig


could this be:

ks.KMSConfiguration = &apiserverv1.KMSConfiguration{ APIVersion: "v2", Name: fmt.Sprintf("%d", keyID), Endpoint: kms.DefaultEndpoint, Timeout: &metav1.Duration{Duration: kms.DefaultTimeout}, }

?

KMSConfig stores Plugin specific configurations (although this is obsolete, I just reference https://github.com/openshift/api/blob/81371d13d1fcad175a48627cf11524a94a80c377/config/v1/types_kmsencryption.go#L36 to show an example of a configuration). So it is bound to APIServer config rather than apiserverv1.KMSConfiguration.

For instance KMS config will likely store AppRole, etc. for Vault in v2.

We need to trigger a new migration, if keyArn (or appRole, etc.) is changed, even though these are not represented in apiserverv1.KMSConfiguration.

would it make sense to focus on v1 in this PR ?
we might change the approach for v2 once we start prototyping.

as far as i can tell a KMSConfig is actually apiserverconfigv1.KMSConfiguration
xref: https://github.com/openshift/library-go/pull/2086/changes#r2773184416

keyArn (or appRole, etc.) is changed, even though these are not represented in apiserverv1.KMSConfiguration.

aren't these changes for a kms plugin ?

i think we need to distinguish two configs: one for a kms plugin and the other one for kms configuration (encryption-cfg)

You are right actually. We may even need a third one to track key_id from Status endpoint. But for v1, I think we can have one.

p0lyn0mial · 2026-02-06T08:19:01Z

pkg/operator/encryption/controllers/key_controller.go

 func (c *keyController) generateKeySecret(keyID uint64, currentMode state.Mode, internalReason, externalReason string) (*corev1.Secret, error) {
-	bs := crypto.ModeToNewKeyFunc[currentMode]()
+	kmsConfig := []byte(kms.DefaultEndpoint)
+	bs := crypto.ModeToNewKeyFunc[currentMode](kmsConfig)


since the key is not used why it can't be 0 as for the identity ?

It will definitely be used in v2. You mean we can remove it for v1, right?

since the key is not used why it can't be 0 as for the identity ?

I think, for v1, we can remove indeed.

I would like to keep this pr simple for v1.
Once we start developing v2 we might change the approach.

yeah, agree. It makes sense. I'm updating.

p0lyn0mial · 2026-02-06T09:40:02Z

pkg/operator/encryption/encryptionconfig/config.go

+			provider := apiserverconfigv1.ProviderConfiguration{
+				// This generated KMSConfiguration can be convertible to KeyState,
+				// since provider name contains the key id and secret.
+				KMS: &apiserverconfigv1.KMSConfiguration{


here, as far as i can tell a KMSConfig is actually apiserverconfigv1.KMSConfiguration.

as far as i can tell we will never store any additional data beyond apiserverconfigv1.KMSConfiguration .

I'm marking this PR as WIP to make necessary changes based on this ^^.

PR has been updated to store apiserverconfigv1.KMSConfiguration.

ardaguclu · 2026-02-06T11:47:03Z

/retitle WIP: CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers

ardaguclu · 2026-02-09T08:57:53Z

/retest

ardaguclu · 2026-02-09T09:55:12Z

/retitle CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers

p0lyn0mial

left a few more questions.
overall it lgtm

p0lyn0mial · 2026-02-09T10:27:48Z

pkg/operator/encryption/encryptionconfig/config.go

+			case provider.KMS != nil:
+				// Since in v1 we don't support kms -> kms migrations, we can use empty key.
+				// Because we don't need to compare secrets to detect change.
+				secret := crypto.ModeToNewKeyFunc[state.KMS]()


would it make sense to define a var for it similar to emptyStaticIdentityKey ?(defined at the top of this file)

yes, it would be nicer. Updated.

p0lyn0mial · 2026-02-09T12:57:20Z

pkg/operator/encryption/encryptionconfig/config.go

+						Name:   keyId,
+						Secret: base64.StdEncoding.EncodeToString(secret),
+					},
+					Mode: state.KMS,


shouldn't we also populate ks.KMSConfiguration ?

Once we set correct keyId and secret to KeyState, backed secret will be found which includes any other field we need (including the KMSConfiguration). KeyState is enriched in here

library-go/pkg/operator/encryption/encryptionconfig/config.go

Lines 115 to 120 in b6adacb

for _, k := range backedKeys {

if state.EqualKeyAndEqualID(&ks, &k) {

ks = k

break

}

}

.

p0lyn0mial · 2026-02-09T13:01:55Z

pkg/operator/encryption/encryptionconfig/config.go

+				// Since in v1 we don't support kms -> kms migrations, we can use empty key.
+				// Because we don't need to compare secrets to detect change.
+				secret := crypto.ModeToNewKeyFunc[state.KMS]()
+				keyId := strings.Split(provider.KMS.Name, "-")[0]


could we create a private function for adding/removing the suffix ?

That would be better. Updated.

p0lyn0mial · 2026-02-09T13:15:21Z

pkg/operator/encryption/crypto/keys.go

 		state.AESGCM:    NewAES256Key,
 		state.SecretBox: NewAES256Key, // secretbox requires a 32 byte key so we can reuse the same function here
 		state.Identity:  NewIdentityKey,
+		state.KMS:       NewIdentityKey,


would it make sense to rename NewIdentityKey to something more generic ?(now used by state.Identity and state.KSM)

Good point. Updated.

p0lyn0mial · 2026-02-09T13:19:34Z

pkg/operator/encryption/encryptionconfig/config.go

+				// Since in v1 we don't support kms -> kms migrations, we can use empty key.
+				// Because we don't need to compare secrets to detect change.
+				secret := crypto.ModeToNewKeyFunc[state.KMS]()
+				keyId := strings.Split(provider.KMS.Name, "-")[0]


I’m still wondering about encapsulation here.
I think other parts of the code won’t even be aware that the name has changed.

Only the code in encryptionconfig/config.go will encode and decode the new name, right?

Do we need to ensure that the name doesn’t already contain "-"?
For simplicity, we could add a comment in the key generation function describing this requirement.

Only the code in encryptionconfig/config.go will encode and decode the new name, right?

That is correct. Rest of the code only deals with KeyState. They do not even know about the details of EncryptionConfiguration.

Do we need to ensure that the name doesn’t already contain "-"?

Kube-apiserver already fails, if it encounters a provider name without -. Because uniqueness has broken.

For simplicity, we could add a comment in the key generation function describing this requirement.

I've added a comment about the reasons behind this provider name generation mechanism. Please let me know your thoughts. Thanks.

benluddy · 2026-02-10T22:11:19Z

pkg/operator/encryption/encryptionconfig/config.go

+func getKeyIDFromProviderName(providerName string) string {
+	// We just need to obtain the keyID to find our backed secret
+	// e.g. "1-secrets"
+	return strings.Split(providerName, "-")[0]


How should this handle an unexpected provider name?

Although it may not be possible, it is better to handle the invalid provider name gracefully. I've updated the code. Please let me know your thoughts.

benluddy · 2026-02-10T22:16:39Z

pkg/operator/encryption/encryptionconfig/config.go

 				},
 			})
+		case state.KMS:
+			// In order to preserve the uniqueness, we should insert resource name


OK, "kms v2 providers name must always be unique across all kms providers (v1 and v2)":

https://github.com/kubernetes/kubernetes/blob/870e2928bc1d9a48a8ef75289ea57ec6cdeb5cb3/staging/src/k8s.io/apiserver/pkg/apis/apiserver/validation/validation_encryption.go#L438-L444

Are there going to be side effects from this naming scheme visible in things like metric labels?

All the metrics that is about provider_name will be affected https://github.com/kubernetes/kubernetes/blob/90a76aaa9afbe9cdb3df5f0a4356018b6637648b/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/metrics/metrics.go#L169.

benluddy · 2026-02-10T22:21:25Z

pkg/operator/encryption/encryptionconfig/config.go

+func createKMSProviderName(keyID, resource string) string {
+	// Ideally we should have used keyId simply in kms provider name.
+	// However, this is an upstream constraint that every provider name must be unique.
+	// To maintain uniqueness while still allowing access to the keyId, we generate provider name in this format.


OK, this is at least less strange than smuggling identity names in phony AES-GCM provider configs. Later, I would be interested in coming up with alternatives that let the controllers correlate provider configs to their source secret without smuggling.

I agree with you. It was error-prone and not nice. Since now we carry KMSConfigurations in backed Secrets, I think we won't need to carry anything in provider_names.

benluddy · 2026-02-10T22:29:29Z

pkg/operator/encryption/controllers/key_controller.go

+		// Moreover, we don't trigger new key when external reason is changed.
+		// Because it would lead to duplicate providers which is not allowed.


IIUC, even if we did roll out a new encryption config in response to the "reason" update, we're not even capable of triggering a KEK rotation unless a specific provider happened to expose that capability independently.

Good point. That is correct.

benluddy · 2026-02-10T22:36:21Z

pkg/operator/encryption/kms/helpers.go

+const (
+	DefaultEndpoint = "unix:///var/run/kmsplugin/kms.sock"
+	DefaultTimeout  = 10 * time.Second
+)


Is there a real need to export these constants? IMO, duplicating the values in tests is good because it requires that changes in observable behavior are accompanied by changes to test expectations. And other code (doing related things like setting up volume mounts) should be observing effective values rather than using hardcoded defaults.

The only reason is to be accessed by key_controller. If we move these constants in there, we don't need to export them.

openshift-ci · 2026-02-11T07:12:29Z

@ardaguclu: all tests passed!

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.

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jan 23, 2026

openshift-ci bot requested review from dgrisonnet and p0lyn0mial January 23, 2026 07:39

ardaguclu force-pushed the kms-mode branch from eb55a0f to 0dcacb4 Compare January 23, 2026 07:48

ardaguclu changed the title ~~CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers~~ WIP: CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers Jan 23, 2026

openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 23, 2026

ardaguclu force-pushed the kms-mode branch from 0dcacb4 to a7cfa5f Compare January 23, 2026 08:50

This was referenced Jan 23, 2026

WIP: Fake vendor library-go openshift/cluster-kube-apiserver-operator#2013

Closed

WIP: Fake vendor library-go openshift/cluster-openshift-apiserver-operator#639

Closed

WIP: Fake vendor library-go openshift/cluster-authentication-operator#824

Closed

ardaguclu changed the title ~~WIP: CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers~~ CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers Jan 23, 2026

openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 23, 2026

ardaguclu changed the title ~~CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers~~ WIP: CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers Jan 23, 2026

openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 23, 2026

ardaguclu force-pushed the kms-mode branch 2 times, most recently from 377c3cb to 0b007f9 Compare January 27, 2026 07:41

ardaguclu changed the title ~~WIP: CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers~~ CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers Jan 27, 2026

openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 27, 2026

openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 27, 2026

ardaguclu force-pushed the kms-mode branch from 0b007f9 to 99f27e5 Compare January 27, 2026 08:18

openshift-ci bot requested review from benluddy and bertinatto and removed request for dgrisonnet January 27, 2026 15:54

openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 5, 2026

This was referenced Feb 5, 2026

CNTRLPLANE-2247:Adding KMS TestKMSEncryptionOnOff test openshift/cluster-kube-apiserver-operator#2027

Merged

CNTRLPLANE-2247:Adding KMS TestKMSEncryptionOnOff test for AUTH openshift/cluster-authentication-operator#834

Merged

p0lyn0mial reviewed Feb 5, 2026

View reviewed changes

ardaguclu force-pushed the kms-mode branch from fc741ef to 8c5e7a2 Compare February 6, 2026 06:34

ardaguclu commented Feb 6, 2026

View reviewed changes

p0lyn0mial reviewed Feb 6, 2026

View reviewed changes

openshift-ci bot changed the title ~~CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers~~ WIP: CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers Feb 6, 2026

openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 6, 2026

ardaguclu force-pushed the kms-mode branch 3 times, most recently from d0321f6 to b8208c8 Compare February 9, 2026 08:16

openshift-ci bot changed the title ~~WIP: CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers~~ CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers Feb 9, 2026

openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 9, 2026

p0lyn0mial reviewed Feb 9, 2026

View reviewed changes

Add KMS encryption mode into library-go encryption controllers

9351ccf

ardaguclu force-pushed the kms-mode branch from b8208c8 to 9351ccf Compare February 10, 2026 06:33

benluddy reviewed Feb 10, 2026

View reviewed changes

Gracefully handle invalid provider name

7fdfa11

	for _, k := range backedKeys {
	if state.EqualKeyAndEqualID(&ks, &k) {
	ks = k
	break
	}
	}

		// Moreover, we don't trigger new key when external reason is changed.
		// Because it would lead to duplicate providers which is not allowed.

CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers #2086

Are you sure you want to change the base?

CNTRLPLANE-2241: Add KMS encryption mode into library-go encryption controllers #2086

Uh oh!

Conversation

ardaguclu commented Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jan 23, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jan 23, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci bot commented Jan 23, 2026

Uh oh!

openshift-ci-robot commented Jan 23, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ardaguclu commented Jan 23, 2026

Uh oh!

ardaguclu commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ardaguclu commented Jan 27, 2026

Uh oh!

p0lyn0mial commented Feb 5, 2026

Uh oh!

p0lyn0mial left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ardaguclu Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ardaguclu Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ardaguclu Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

p0lyn0mial left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ardaguclu commented Jan 23, 2026 •

edited

Loading

openshift-ci-robot commented Jan 23, 2026 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Jan 23, 2026 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Jan 23, 2026 •

edited by openshift-ci bot

Loading

ardaguclu commented Jan 27, 2026 •

edited

Loading

ardaguclu Feb 5, 2026 •

edited

Loading

ardaguclu Feb 6, 2026 •

edited

Loading

ardaguclu Feb 6, 2026 •

edited

Loading

ardaguclu commented Feb 6, 2026 •

edited by openshift-ci bot

Loading

ardaguclu commented Feb 9, 2026 •

edited by openshift-ci bot

Loading