Skip to content

exoscale_kms_key (Resource)

Manage Exoscale KMS Keys.

Example Usage

resource "exoscale_kms_key" "my_key" {
  zone        = "ch-gva-2"
  name        = "my-key"
  description = "my key description"
}

The supported combinations of usage and key_spec are:

key_specencrypt-decryptsign-verify
AES_256 (default)✅
RSA_3072, RSA_4096✅✅
ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521, ECC_EDWARDS25519✅
ML_DSA_65, ML_DSA_87✅

A signing key needs an asymmetric key_spec:

resource "exoscale_kms_key" "my_signing_key" {
  zone     = "ch-gva-2"
  name     = "my-signing-key"
  usage    = "sign-verify"
  key_spec = "ECC_NIST_P256"
}

A key backed by an External Key Store (beta) only supports usage = "encrypt-decrypt", key_spec = "AES_256" and single-zone keys. The key store must be connected:

resource "exoscale_kms_key" "my_external_key" {
  zone = "ch-gva-2"
  name = "my-external-key"

  xks = {
    key_store_id    = "<key-store-id>"
    external_key_id = "<external-key-id>"
  }
}

Please refer to the examples directory for complete configuration examples.

Schema

Required

  • name (String) ❗ The name of the KMS Key.
  • zone (String) ❗ The Exoscale Zone name.

Optional

  • description (String) ❗ A description of the KMS Key.
  • key_spec (String) ❗ The cryptographic key specification (default: AES_256).
  • multi_zone (Boolean) ❗ Whether the key is replicated across multiple zones.
  • timeouts (Block, Optional) (see below for nested schema)
  • usage (String) ❗ The key usage purpose: encrypt-decrypt or sign-verify (default: encrypt-decrypt).
  • xks (Attributes) ❗ [BETA] Back the key with a key held in an External Key Store. Only usage = "encrypt-decrypt", key_spec = "AES_256" and single-zone keys are supported. (see below for nested schema)

Read-Only

  • id (String) The ID of this resource.
  • source (String) The source of the key material: exoscale-kms, or external-key-store when xks is set.
  • status (String) The current status of the KMS Key.

Nested Schema for timeouts

Optional:

  • create (String) A string that can be parsed as a duration consisting of numbers and unit suffixes, such as “30s” or “2h45m”. Valid time units are “s” (seconds), “m” (minutes), “h” (hours).
  • delete (String) A string that can be parsed as a duration consisting of numbers and unit suffixes, such as “30s” or “2h45m”. Valid time units are “s” (seconds), “m” (minutes), “h” (hours). Setting a timeout for a Delete operation is only applicable if changes are saved into state before the destroy operation occurs.
  • read (String) A string that can be parsed as a duration consisting of numbers and unit suffixes, such as “30s” or “2h45m”. Valid time units are “s” (seconds), “m” (minutes), “h” (hours). Read operations occur during any refresh or planning operation when refresh is enabled.
  • update (String) A string that can be parsed as a duration consisting of numbers and unit suffixes, such as “30s” or “2h45m”. Valid time units are “s” (seconds), “m” (minutes), “h” (hours).

Nested Schema for xks

Required:

  • external_key_id (String) ❗ The ID of the key as known to the XKS proxy.
  • key_store_id (String) ❗ The ID of the External Key Store.

-> The symbol ❗ in an attribute indicates that modifying it, will force the creation of a new resource.

Deletion

KMS keys cannot be deleted immediately. Destroying an exoscale_kms_key schedules the deletion of the key in 7 days; during that period the key is pending-deletion, can no longer be used, and is no longer tracked by Terraform.

A pending-deletion key keeps its name until it is actually deleted. For that reason, a change that forces the creation of a new key (❗) must also change name, otherwise the plan fails. Data encrypted with the previous key can only be decrypted with that key.

~> terraform apply -replace and terraform taint force a new key without changing any attribute, so the provider cannot stop them: the current key is scheduled for deletion, then creating its replacement fails because the name is still reserved. Setting lifecycle { create_before_destroy = true } on the key makes Terraform create the replacement first, so that the failure happens before the current key is touched.

Recover a key scheduled for deletion

Terraform cannot cancel a scheduled deletion. To recover the key before the 7 days have passed:

  1. Cancel the deletion. The key is restored in the disabled state:
exo kms key cancel-deletion <key-id> --zone <zone>
  1. Enable the key:
exo kms key enable <key-id> --zone <zone>
  1. Import the key back into Terraform (see Import).

Import

An existing KMS key may be imported by <ID>@<zone>:

terraform import \
  exoscale_kms_key.my_key \
  019ef461-c0ae-7c9c-94bd-081e70fe2b08@ch-gva-2
Last updated on