Browse the Repo

file-type-icon.circleci
file-type-iconexamples
file-type-iconmodules
file-type-iconcloud-kms
file-type-iconREADME.md
file-type-iconlocals.tf
file-type-iconmain.tf
file-type-iconoutputs.tf
file-type-iconvariables.tf
file-type-icontest
file-type-icon.editorconfig
file-type-icon.gitignore
file-type-icon.pre-commit-config.yaml
file-type-iconCODEOWNERS
file-type-iconCONTRIBUTING.md
file-type-iconGRUNTWORK_PHILOSOPHY.md
file-type-iconLICENSE.txt
file-type-iconNOTICE
file-type-iconREADME.md
file-type-iconmain.tf
file-type-iconoutputs.tf
file-type-iconvariables.tf

Browse the Repo

file-type-icon.circleci
file-type-iconexamples
file-type-iconmodules
file-type-iconcloud-kms
file-type-iconREADME.md
file-type-iconlocals.tf
file-type-iconmain.tf
file-type-iconoutputs.tf
file-type-iconvariables.tf
file-type-icontest
file-type-icon.editorconfig
file-type-icon.gitignore
file-type-icon.pre-commit-config.yaml
file-type-iconCODEOWNERS
file-type-iconCONTRIBUTING.md
file-type-iconGRUNTWORK_PHILOSOPHY.md
file-type-iconLICENSE.txt
file-type-iconNOTICE
file-type-iconREADME.md
file-type-iconmain.tf
file-type-iconoutputs.tf
file-type-iconvariables.tf
KMS

KMS

Encrypt and decrypt secrets using Google's Key Management Service (KMS).

Code Preview

Preview the Code

mobile file icon

README.md

down

Cloud KMS Module

This Terraform Module creates a new Cloud KMS keyring, KMS keys and IAM role bindings to control access to the keys.

How do you use this module?

What is Cloud KMS?

Cloud KMS is a cloud-hosted key management service that lets you manage cryptographic keys for your cloud services the same way you do on-premises. You can generate, use, rotate, and destroy AES256, RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384 cryptographic keys.

Cloud KMS is integrated with Cloud IAM and Cloud Audit Logging so that you can manage permissions on individual keys and monitor how these are used. Use Cloud KMS to protect secrets and other sensitive data that you need to store in Google Cloud Platform.

Managing Key IAM bindings

The predefined roles allow for a separation of duties, where it is needed.

This module declares three levels of access to the keys. For encryption keys (both symmetric and asymmetric), you can declare the following access levels:

  1. Key Admin: is meant for users who manage the keys but not use them.

  2. Key Encrypter: is meant for users who can use a key to encrypt data, but not decrypt or manage keys.

  3. Key Decrypter: is meant for users who can use a key to decrypt data, but not encrypt or manage keys.

For signing keys, the access levels are:

  1. Key Admin: is meant for users who manage the keys but not use them.

  2. Key Signers: is meant for users who can use a key to sign data, but not verify or manage keys.

  3. Key Verifiers: is meant for users who can use a key to sign and verify data, but not manage keys.

See the following example to learn how to set the IAM bindings.

Key configuration example

  ...

  symmetric_keys = {
    my-symmetric-key = {
      protection_level = "SOFTWARE"
      // Automatic key rotation only supported for symmetric keys
      rotation_period  = "90000s"
      admins           = ["user:adminuser@acme.org"]
      encrypters       = ["group:encrypters@acme.org"]
      decrypters       = ["serviceAccount:sa@acme.org"]
      labels           = {
        org-unit = "Acme"
      }
    },
  }

  asymmetric_keys = {
    my-asymmetric-key = {
      protection_level = "SOFTWARE"
      algorithm        = "RSA_DECRYPT_OAEP_3072_SHA256"
      admins           = ["user:adminuser@acme.org"]
      encrypters       = ["group:encrypters@acme.org"]
      decrypters       = ["serviceAccount:sa@acme.org"]
      labels           = {}
    },
  }

  signing_keys = {
    my-signin-key = {
      algorithm        = "RSA_SIGN_PSS_3072_SHA256"
      protection_level = "HSM"
      admins           = ["user:adminuser@acme.com"]
      signers          = ["group:signers@acme.com"]
      verifiers        = ["group:verifiers@acme.com"]
      labels           = {}
    },
  }

  ...

Lifetime of objects

Key ring and key resources CANNOT be deleted. Key versions also cannot be deleted, but key version material can be destroyed so that the resources can no longer be used. The inability to delete key rings, keys, and key versions ensures a key version resource identifier always points to only its original key material.

Key rings and keys do not have billable costs or quota limitations, so their continued existence does not impact costs or production limits.

Questions? Ask away.

We're here to talk about our services, answer any questions, give advice, or just to chat.

Ready to hand off the Gruntwork?