Config Store-backed Vaults

A KongVault with backend: konnect stores its secrets in a Konnect Config Store, which is identified by a config_store_id. Instead of creating the Config Store out-of-band and copying its ID into spec.config, you can manage the Config Store with a KonnectConfigStore resource and reference it from spec.configStoreRef.

Four Kubernetes resources describe the setup:

The secret value itself is the one step that isn’t declarative: it’s written straight to Konnect, out-of-band, to avoid storing the secret value in etcd.

• spec.configStoreRef is only supported with backend: konnect, and it’s mutually exclusive with setting config_store_id under spec.config.
• spec.prefix is what you use in vault references later, and it’s immutable after creation.
• KongVault is cluster-scoped and KonnectConfigStore is namespaced, so the reference always crosses a namespace boundary and requires a KongReferenceGrant.
• Kong Operator reports the outcome of the reference in the ConfigStoreRefValid condition.

Referencing a secret from a Config Store moves it out of every place you manage with GitOps, but it doesn’t remove it from Konnect:

Anyone who can write secrets into the Config Store can replace the key that your listener serves, so treat Config Store write access as equivalent to certificate issuance rights.

• Deleting the KonnectConfigStore deletes the Config Store in Konnect along with every secret stored in it, including keys that other Vaults or certificates still reference. Delete it only when you’re sure nothing depends on its contents.
• spec.configStoreRef is mutable. Removing it clears the ConfigStoreRefValid condition and leaves any config_store_id you set directly under spec.config untouched.
• Removing the KongReferenceGrant stops further updates to a programmed KongVault, but the Vault that already exists in Konnect, including its config_store_id, isn’t rolled back or removed.
• Rotating a key is a Config Store operation: update the secret value in place, and the vault reference keeps resolving without any change to your Kubernetes resources.