Overview

Cloud Key Management Service allows you to create, import, and manage cryptographic keys and perform cryptographic operations in a single centralized cloud service. You can use these keys and perform these operations by using Cloud KMS directly, by using Cloud HSM or Cloud External Key Manager, or by using Customer-Managed Encryption Keys (CMEK) integrations within other Google Cloud services.

With Cloud KMS you are the ultimate custodian of your data, you can manage cryptographic keys in the cloud in the same ways you do on-premises, and you have a provable and monitorable root of trust over your data.

Cloud KMS resources

Keys

A Cloud KMS key is a named object containing one or more key versions, along with metadata for the key. A key exists on exactly one key ring tied to a specific location.

You can allow and deny access to keys using Identity and Access Management (IAM) permissions and roles. It’s not possible to manage access to a key version.

Disabling or destroying a key also disables or destroys each key version.

Type

A key’s type determines whether the key is used for symmetric or asymmetric cryptographic operations.

In symmetric encryption, the entire key is required to encrypt or decrypt data. Symmetric keys cannot be used for signing.

In asymmetric encryption or signing, the key consists of a public and private key.

• The private key is considered sensitive data, and is required to decrypt data or for signing, depending on the key’s configured purpose.
• The public key is not considered sensitive, and is required to encrypt data or to verify a signature, depending on the key’s configured purpose.A key’s type can’t be changed after the key is created.

A key’s type is one component of its purpose.

Purpose

A key’s purpose determines whether the key can be used for encryption or for signing. You choose the purpose when creating the key, and all versions have the same purpose.

The purpose of a symmetric key is always Symmetric encrypt/decrypt.

The purpose of an asymmetric key is either Asymmetric encrypt/decrypt or Asymmetric signing.

A key’s purpose can’t be changed after the key is created.

Primary version

A key has multiple versions, but a symmetric key can have at most one primary key version. The primary key version is used to encrypt data if you do not specify a key version.

Asymmetric keys do not have primary versions; you must specify the version when using the key.

For both symmetric and asymmetric keys, you can use any enabled key version to encrypt or decrypt data, whether it is the primary version or not.

Key versions

Each version of a key contains key material used for encryption or signing. A key’s version is represented by an integer, starting at 1.

To decrypt data or verify a signature, you must use the same key version that was used to encrypt or sign the data.

You can disable or destroy a key version without affecting other versions. Rotating a key creates a new version.

Disabling or destroying a key also disables or destroys all versions of that key. You can selectively disable a key version without affecting other key versions.

It’s not possible to manage access to a key version. Granting access to a key also grants access to all of its enabled versions.

For security reasons, no Google Cloud principal can view or export the raw cryptographic key material represented by a key version. Instead, Cloud KMS accesses the key material on your behalf.

State

A key version’s state is always one of the following:

• Enabled
• Disabled
• Scheduled for destruction
• Destroyed

A key version can only be used when it is enabled. Only enabled keys and key versions incur costs.

Protection level

A key version’s protection level determines the key’s storage environment at rest. The protection level is one of the following:

• Software (SOFTWARE in the Cloud SDK and Cloud Key Management Service API)
• HSM
• External (EXTERNAL in the Cloud SDK and Cloud Key Management Service API)

Although the protection level is a property of a key version, it cannot be changed after the key is created.

Algorithm

A key version’s algorithm determines how the key material is created and the parameters required for cryptographic operations. Symmetric and asymmetric keys support different algorithms.

If you do not specify an algorithm when creating a new key version, the algorithm from the previous version is used.

Regardless of the algorithm, Cloud KMS uses probabilistic encryption, so that the same plaintext encrypted with the same key version twice does not encrypt to the same ciphertext.

Key rings

A key ring organizes keys in a specific Google Cloud location and allows you to manage access control on groups of keys. A key ring’s name does not need to be unique across a Google Cloud project, but must be unique within a given location. After creation, a key ring cannot be deleted. Key rings do not incur storage costs.

Retrieving a resource’s ID

Some API calls and gcloud tool might require you to refer to a key ring, key, or key version by its resource ID, which is a string representing the fully-qualified CryptoKeyVersion name. Resource IDs are hierarchical, similar to a filesystem path. A key’s resource ID also contains information about the key ring and location.

Resource life cycles

Key rings, keys, and key versions cannot be deleted. This ensures that a key version’s resource identifier is unique and always points to the original key material for that key version. You can store an unlimited number of key rings, enabled or disabled keys, and enabled or disabled key versions.

Creating KMS key-ring and Crypto-Key using Terraform

1. Enable the Cloud Key Management Service API :

Go to Navigation Menu > API and Services > Library. Search for Enable the Cloud Key Management Service API and enable it if not enabled.

2. Now open Google Cloud Shell and create Directory structure and main.tf as Below:

main.tf

resource "google_kms_key_ring" "keyring" {
  name     = "keyring-example"
  location = "global"
}

resource "google_kms_crypto_key" "example-key" {
  name            = "crypto-key-example"
  key_ring        = google_kms_key_ring.keyring.id
  rotation_period = "100000s"

  lifecycle {
    prevent_destroy = true
  }
}

3. Now initialize “Terraform”.

terraform init

4. Validate terraform script:

terraform validate

5. Perform Terraform plan.

terraform plan

6. Perform Terraform apply.

terraform apply

7. Now go to Navigation Menu > Security > Key Management. You will see that the key-ring named “keyring-example” has been created.

8. Click on the “keyring-example”, you will see that a kms key called “crypto-key-example” has been created.

9. Now click on “crypto-key-example” to see its properties. you will see that version is 1.

This concludes our tutorial on Creating KMS key using Terraform !!

Happy Learning !!!