k3s-io/k3s · error

unsupported encryption keys found

Error message

unsupported encryption keys found

What it means

When reading the cluster's EncryptionConfiguration, getEncryptionKeys only understands the identity, aescbc, and secretbox providers. Encountering an aesgcm or kms provider means the config was created by something this code path cannot model or re-encrypt, so it refuses rather than silently dropping keys.

Source

Thrown at pkg/secretsencrypt/config.go:97

	}
	if len(providers) > 3 {
		return nil, fmt.Errorf("more than 3 providers (%d) found in secrets encryption", len(providers))
	}

	for _, p := range providers {
		// Since identity doesn't have keys, we make up a fake key to represent it, so we can
		// know that encryption is enabled/disabled in the request.
		if p.Identity != nil {
			currentKeys.Identity = true
		}
		if p.AESCBC != nil {
			currentKeys.AESCBCKeys = append(currentKeys.AESCBCKeys, p.AESCBC.Keys...)
		}
		if p.Secretbox != nil {
			currentKeys.SBKeys = append(currentKeys.SBKeys, p.Secretbox.Keys...)
		}
		if p.AESGCM != nil || p.KMS != nil {
			return nil, errors.New("unsupported encryption keys found")
		}
	}
	return currentKeys, nil
}

// WriteEncryptionConfig writes the encryption configuration to the file system.
// The provider arg will be placed first, and is used to encrypt new secrets.
func WriteEncryptionConfig(runtime *config.ControlRuntime, keys *EncryptionKeys, provider string, enable bool) error {
	var providers []apiserverconfigv1.ProviderConfiguration
	var primary apiserverconfigv1.ProviderConfiguration
	var secondary *apiserverconfigv1.ProviderConfiguration
	switch provider {
	case AESCBCProvider:
		primary = apiserverconfigv1.ProviderConfiguration{
			AESCBC: &apiserverconfigv1.AESConfiguration{
				Keys: keys.AESCBCKeys,
			},
		}

View on GitHub (pinned to 6ba341e396)

Solutions

  1. Switch the EncryptionConfiguration to the supported providers: secretbox (recommended) or aescbc, keeping identity first/last as needed.
  2. If the cluster relies on KMS/aesgcm by design, stop using the secrets-encrypt tooling for it - it will not operate those keys.
  3. After fixing, ensure secrets are decrypted with the old provider before removing it (rotate via kubectl and verify).

Example fix

# before: EncryptionConfiguration with aesgcm/kms provider
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources: [ { providers: [ { aesgcm: { keys: [...] } } ] } ]
# after
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources: [ { providers: [ { secretbox: { keys: [ { name: key1, secret: <32-byte-base64> } ] } } ] } ]
Defensive patterns

Strategy: validation

Validate before calling

for _, p := range providers {
    if p.AESGCM != nil || p.KMS != nil {
        return errors.New("unsupported encryption provider (aesgcm/kms); use secretbox or aescbc")
    }
}

Prevention

When it happens

Trigger: Running secrets-encrypt operations (status, rotate, reencrypt) on a cluster whose EncryptionConfiguration resource or file includes an AES-CBC+GCM(aesgcm) or KMS v2 provider - typically hand-edited or applied from external tooling.

Common situations: Operators pasting upstream Kubernetes encryption configs that use aesgcm/kms; migration from a distribution that enabled KMS; re-enabling encryption after manually changing providers.

Related errors


AI-assisted analysis of k3s-io/k3s@6ba341e396 (2026-08-15). Data as JSON: /api/errors/04bb3759d2cc4752. Report an issue: GitHub.