This Banner is For Sale !!
Get your ad here for a week in 20$ only and get upto 15k traffic Daily!!!

Creating a multi-region key using terraform


For organizations to encrypt their knowledge in a cloud-native strategy AWS supplies a completely managed service AWS KMS, a high-performance key administration system with the “pay as you go” mannequin to decrease prices and scale back their administration burden in comparison with self-managed hardware security module (HSM).

By selecting AWS KMS organizations get three choices for encryption key administration:

  • AWS KMS with buyer or AWS-managed keys
  • AWS KMS with BYOK
  • AWS KMS with a KMS customized key retailer key administration backed by CloudHSM

Terraform AWS provider model 3.64.0 launched new useful resource aws_kms_replica_key by which we will create Customer Managed Key (CMK).

On this weblog put up, we are going to walkthrough the steps for making a multi-region CMK utilizing the useful resource aws_kms_replica_key which was launched newly in Terraform AWS provider model 3.64.0.

Multi-Area keys turn out to be useful for knowledge safety eventualities – Catastrophe restoration, International knowledge administration, Distributed signing purposes, Lively-active purposes that spun a number of areas.

As we’d like the useful resource kind aws_kms_replica_key from Terraform AWS supplier the under block helps so as to add this to our mission. Ensure you have atleast 3.64.0 model to attain this.

terraform {
  required_providers {
    aws = {
      supply  = "hashicorp/aws"
      model = "~> 3.64.0"
    }
  }
}
Enter fullscreen mode

Exit fullscreen mode

Multi-Area keys should not international. You create a multi-Area main key after which replicate it into areas that you choose inside an AWS partition. You then handle the Multi-Area key in every area independently.

In our case we may have the first key created in Singapore area whereas the replicas in Sydney and Jakarta respectively.

# Singapore
supplier "aws" {
  area = "ap-southeast-1"
}

# Sydney
supplier "aws" {
  alias  = "secondary"
  area = "ap-southeast-2"
}

# Jakarta
# 3.70.0 Terraform AWS Supplier launch will use AWS SDK v1.42.23 
# which provides ap-southeast-3 to the checklist of areas for the usual AWS partition.
# https://github.com/hashicorp/terraform-provider-aws/points/22252
supplier "aws" {
  alias  = "tertiary"
  area = "ap-southeast-3"
  skip_region_validation = true
}
Enter fullscreen mode

Exit fullscreen mode

NOTE: If you’re making an attempt to create a KMS duplicate in JAKARTA area you’ll encounter an error as under
Error: Invalid AWS Area: ap-southeast-3
with supplier[“registry.terraform.io/hashicorp/aws”].tertiary,

That is becuase help for ap-southeast-3 was added in AWS SDK v1.42.23 and utilized in Terraform AWS Supplier v3.70.0. The short-term resolution for this may be so as to add skip_region_validation = true assertion within the supplier block.

In contrast to different AWS useful resource insurance policies, a AWS KMS key coverage doesn’t mechanically give permission to the account or any of its customers. To provide permission to account directors, the important thing coverage should embrace an express assertion that gives this permission, like this one.

knowledge "aws_iam_policy_document" "kms" {
  # Permit root customers full administration entry to key
  assertion {
    impact = "Permit"
    actions = [
      "kms:*"
    ]
    assets = ["*"]
    principals {
      kind        = "AWS"
      identifiers = ["arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"]
    }
  }

  # Permit different accounts restricted entry to key
  assertion {
    impact = "Permit"
    actions = [
      "kms:CreateGrant",
      "kms:Encrypt",
      "kms:Decrypt",
      "kms:ReEncrypt*",
      "kms:GenerateDataKey*",
      "kms:DescribeKey",
    ]

    assets = ["*"]

    # AWS account IDs that want entry to this key
    principals {
      kind        = "AWS"
      identifiers = var.account_ids
    }
  }
}
Enter fullscreen mode

Exit fullscreen mode



Creating multi-region main key

useful resource "aws_kms_key" "main" {
  description         = "CMK for AWS CB Weblog"
  enable_key_rotation = true
  coverage              = knowledge.aws_iam_policy_document.kms.json
  multi_region        = true
}
Enter fullscreen mode

Exit fullscreen mode

Useful resource :aws_kms_key is used to create a single-region OR multi-region main KMS key.

As it is a multi-region key the id & key_id has mrk- as prefix.

terraform present -json terraform.tfstate | jq '.values.root_module.assets[0].values.id'
"mrk-01641fdcadec421f9ed2665c7d78ef9c"

terraform present -json terraform.tfstate | jq '.values.root_module.assets[0].values.key_id'
"mrk-01641fdcadec421f9ed2665c7d78ef9c"
Enter fullscreen mode

Exit fullscreen mode

It’s also possible to consult with KMS key utilizing its alias. Useful resource : aws_kms_alias is used to create an alias.

useful resource "aws_kms_alias" "alias" {
  target_key_id = aws_kms_key.main.id
  title          = format("alias/%s", decrease("AWS_CB_CMK"))
}
Enter fullscreen mode

Exit fullscreen mode

NOTE: “title” should start with ‘alias/’ and be comprised of solely [a-zA-Z0-9:/_-]

AWS KMS CMK



Creating multi-region duplicate keys

useful resource "aws_kms_replica_key" "secondary" {
  supplier = aws.secondary

  description             = "Multi-Area duplicate key"
  deletion_window_in_days = 7
  primary_key_arn         = aws_kms_key.main.arn
}

useful resource "aws_kms_replica_key" "tertiary" {
  supplier = aws.tertiary

  description             = "Multi-Area duplicate key"
  deletion_window_in_days = 7
  primary_key_arn         = aws_kms_key.main.arn
}
Enter fullscreen mode

Exit fullscreen mode

Useful resource :aws_kms_replica_key is used to create a multi-region duplicate key. Right here we’re passing explicitly the supplier alias (aws.secondary & aws.tertiary) to create the keys in Sydney & Jakarta area.

MRK

It’s good to set a ready interval of seven (min) – 30 (max, default) days for deleting the KMS key.

We thus have a main key in Singapore area with its duplicate in Sydney & Jakarta respectively.

Whilst you implement this and in continuation of this weblog we are going to see

  • How we will eat this key in encrypting an S3 bucket to configure AWS CloudTrail
  • Configure an SQS
  • Integrating Azure Sentinel to eat AWS CloudTrail knowledge.

The Article was Inspired from tech community site.
Contact us if this is inspired from your article and we will give you credit for it for serving the community.

This Banner is For Sale !!
Get your ad here for a week in 20$ only and get upto 10k Tech related traffic daily !!!

Leave a Reply

Your email address will not be published. Required fields are marked *

Want to Contribute to us or want to have 15k+ Audience read your Article ? Or Just want to make a strong Backlink?