Cryptographic keys should be rotated periodically to limit the impact of a compromised key.

Why is this an issue?

The likelihood of security incidents increases when cryptographic keys are used for a long time without rotation. Symmetric keys created with the Google Cloud Key Management Service (KMS) support automatic rotation, which limits the amount of data that can be decrypted by an attacker if a key is compromised. This rule raises an issue when a google_kms_crypto_key resource is created without a rotation_period configured. Note that it is not possible in GCP KMS to rotate asymmetric keys automatically.

What is the potential impact?

Exposure of sensitive data

If a symmetric key is compromised and no rotation period is configured, all data encrypted with that key remains vulnerable indefinitely. An attacker who obtains the key material can decrypt historical data until the key is manually revoked or replaced. Automatic rotation limits this exposure to only the data encrypted during the current key version’s validity period.

How to fix it

Code examples

The following code is vulnerable because the KMS crypto key is created without a rotation_period, meaning the key is never automatically rotated.

Noncompliant code example

resource "google_kms_crypto_key" "example-key" { # Noncompliant: no rotation period is defined
  name     = "example"
  key_ring = google_kms_key_ring.keyring.id
}

Compliant solution

resource "google_kms_crypto_key" "example-key" {
  name            = "example"
  key_ring        = google_kms_key_ring.keyring.id
  rotation_period = "7776000s" # 90 days
}