Review Cloud KMS key rotation periods

Description

Using one encryption key version for a long time can increase the amount of data that depends on it. Set Cloud KMS rotation periods according to data sensitivity and organizational policy; 90 days is not a mandatory service-wide maximum for every use.

Automatic rotation creates a new primary version for a symmetric ENCRYPT_DECRYPT key. It does not re-encrypt existing data or disable or delete older versions. Asymmetric keys need a separate replacement plan.

Potential impact

A period longer than policy permits may fail key management or audit requirements.
Deleting an older version too soon can make existing data impossible to decrypt.

Remediation

Set rotation_period to the interval required by your organization and verify the actual schedule. Test application use of the new version and retain older versions while existing data depends on them. Manage key access, re-encryption and destruction procedures separately.

Examples

These examples configure a symmetric encryption key. Supply matching actual project, key ring and authentication file values. The two before tasks are alternatives, not a sequence to run against the same key.

Before

yaml

- name: create a crypto key
  google.cloud.gcp_kms_crypto_key:
    name: test_object
    key_ring: projects/{{ gcp_project }}/locations/us-central1/keyRings/key-key-ring
    project: test_project
    auth_kind: serviceaccount
    rotation_period: "315356000s"
    service_account_file: "/tmp/auth.pem"
    state: present

- name: create a crypto key2
  google.cloud.gcp_kms_crypto_key:
    name: test_object
    key_ring: projects/{{ gcp_project }}/locations/us-central1/keyRings/key-key-ring
    project: test_project
    auth_kind: serviceaccount
    service_account_file: "/tmp/auth.pem"
    state: present

The first task sets an interval of roughly ten years; the second does not specify rotation. Omission alone does not remove an existing key’s rotation schedule.

After