Google Cloud Key Management Service Crypto Key

This page shows how to write Terraform for Cloud Key Management Service Crypto Key and write them securely.

google_kms_crypto_key (Terraform)

The Crypto Key in Cloud Key Management Service can be configured in Terraform with the resource name google_kms_crypto_key. The following sections describe 5 examples of how to use the resource and its parameters.

Example Usage from GitHub
resource "google_kms_crypto_key" "key_good_1" {
  name = "crypto-key-example"
  key_ring =
  rotation_period = "100000s"

  lifecycle {
resource "google_kms_crypto_key" "terraform-state" {
  name            = "terraform-state"
  key_ring        =
  rotation_period = "7776000s"

  lifecycle {
resource "google_kms_crypto_key" "key_good_1" {
  name = "crypto-key-example"
  key_ring =
  rotation_period = "100000s"

  lifecycle {
resource "google_kms_crypto_key" "root" {
  name            = local.boundary_root_key_name
  key_ring        =
  rotation_period = var.kms_crypto_key_rotation_period
resource "google_kms_crypto_key" "key" {
  count           = var.prevent_destroy ? length(var.keys) : 0
  name            = var.keys[count.index]
  key_ring        = google_kms_key_ring.key_ring.self_link
  rotation_period = var.key_rotation_period

Review your Terraform file for Google best practices

Shisho Cloud, our free checker to make sure your Terraform configuration follows best practices, is available (beta).

Security Best Practices for google_kms_crypto_key

There is 1 setting in google_kms_crypto_key that should be taken care of for security reasons. The following section explain an overview and example code.


Ensure your KMS key is rotated at least every 90 days

It is better to rotate your KMS key at least every 90 days to reduce the risk of compromise.

Review your Google Cloud Key Management Service settings

You can check if the google_kms_crypto_key setting in your .tf file is correct in 3 min with Shisho Cloud.


The KeyRing that this key belongs to. Format: ''projects/[[project]]/locations/[[location]]/keyRings/[[keyRing]]''.

  • labels optional - map from string to string

Labels with user-defined metadata to apply to this resource.

The resource name for the CryptoKey.

The immutable purpose of this CryptoKey. See the purpose reference for possible inputs. Default value: "ENCRYPT_DECRYPT" Possible values: ["ENCRYPT_DECRYPT", "ASYMMETRIC_SIGN", "ASYMMETRIC_DECRYPT"]

Every time this period passes, generate a new CryptoKeyVersion and set it as the primary. The first rotation will take place after the specified period. The rotation period has the format of a decimal number with up to 9 fractional digits, followed by the letter 's' (seconds). It must be greater than a day (ie, 86400).

The self link of the created KeyRing in the format projects/[project]/locations/[location]/keyRings/[name].

If set to true, the request will create a CryptoKey without any CryptoKeyVersions. You must use the 'google_kms_key_ring_import_job' resource to import the CryptoKeyVersion.

Explanation in Terraform Registry

A CryptoKey represents a logical key that can be used for cryptographic operations.

Note: CryptoKeys cannot be deleted from Google Cloud Platform. Destroying a Terraform-managed CryptoKey will remove it from state and delete all CryptoKeyVersions, rendering the key unusable, but will not delete the resource from the project. When Terraform destroys these keys, any data previously encrypted with these keys will be irrecoverable. For this reason, it is strongly recommended that you add lifecycle hooks to the resource to prevent accidental destruction. To get more information about CryptoKey, see:

Frequently asked questions

What is Google Cloud Key Management Service Crypto Key?

Google Cloud Key Management Service Crypto Key is a resource for Cloud Key Management Service of Google Cloud Platform. Settings can be wrote in Terraform.

Where can I find the example code for the Google Cloud Key Management Service Crypto Key?

For Terraform, the SnidermanIndustries/checkov-fork, ulamlabs/gcp-terraform-starter and melscoop-test/check source code examples are useful. See the Terraform Example section for further details.


Automate config file reviews on your commits

Fix issues in your infrastructure as code with auto-generated patches.