feat!: Restricting autokey module to autokey configuration use case

[nb-goog]

In this PR,

1. Restricting autokey module function to only configure and enable autokey on an input folder number. Deleted configuration responsible for creating keyhandle from the input map.
2. Added two examples
   2.1 for enabling autokey config on a project
   2.2 for creating a bucket using autokey

[romanini-ciandt]

/gcbrun

[romanini-ciandt]

Just for my own understanding, why is it better to keep google_kms_key_handle resource outside the terraform-google-kms module scope?

[romanini-ciandt]

Importing Autokey Key Handles Guidance will be impacted with this PR. The migrating instructions provided there won't work anymore.

Since the changes in this PR are totally removing the Key Handle creation responsibility from terraform-google-kms module, I would recommend deleting that guidance file, since it won't make sense to provide an importing path to a resource that the KMS terraform module won't be creating/managing anymore. (If we delete that, we should also delete the scripts folder)

[nb-goog]

make sense, keeping this comment open till I have approval from all of you reviewers.

[romanini-ciandt]

We need to update the existing autokey tests in order to make CI test the changes implemented in this PR.

[nb-goog]

Do you know how to run the test locally to verify its working?

[romanini-ciandt]

Basically, you need to run a terraform apply in test/setup, and then go test -v in test/integration/autokey_example.

Here's the blueprint-test doc part explaining with more details!

[romanini-ciandt]

FYI the CI is still failing due to this reason

[nb-goog]

tested in local , the test are running fine. Will check the logs

[nb-goog]

Just for my own understanding, why is it better to keep google_kms_key_handle resource outside the terraform-google-kms module scope?

KMS has two personas

1. key admin
2. Key users (developers, etc

key admin should only focus on key management policies and setups AND shouldnt have access to kms keys created.

The keyhandle creation and access to keys is for second persona (key users) thats why we are separating it out

[romanini-ciandt]

Just for my own understanding, why is it better to keep google_kms_key_handle resource outside the terraform-google-kms module scope?

KMS has two personas

1. key admin
2. Key users (developers, etc

key admin should only focus on key management policies and setups AND shouldnt have access to kms keys created.

The keyhandle creation and access to keys is for second persona (key users) thats why we are separating it out

If the only motivation to cut google_kms_key_handle from KMS module is to handle the different personas, how about we implement a change that would accommodate that capability while still keep the benefits of the module?

Suggestion: we could turn google_kms_autokey_config creation optional when using autokey's submodule. google_kms_key_handle is already optional, based on user inputs. That way, key admins could use autokey's submodule passing the desired inputs to create just the Autokey Configuration, while key users could also use autokey's submodule but passing different inputs in order to just create the Key Handle.

To be more clear, the module's usage would be something like that:

# Key admins usage example
module "autokey" {
  source  = "terraform-google-modules/kms/google//modules/autokey"
  version = "3.1.0"

  project_id            = "project-bar"
  autokey_configuration_folder = "123456789"
  }
}

# Key users usage example
module "autokey" {
  source  = "terraform-google-modules/kms/google//modules/autokey"
  version = "3.1.0"

  autokey_handles = {
    storage_bucket = {
      name                   = "bucket-key-handle",
      project                = "project-foo",
      resource_type_selector = "storage.googleapis.com/Bucket",
      location               = "us-central1"
    },
    compute_disk = {
          name                   = "disk-key-handle",
          project                = "project-foo2",
          resource_type_selector = "compute.googleapis.com/Disk",
          location               = "us-central1"
    }
   # It would be possible to create multiple Key Handles here, if desired.
  }
}

Some benefits of using the KMS module approach:

• Customers (key users) could create multiple Key Handles using a single terraform module call;
• By using modules, customers could take leverage from "version", bringing more stability to their environments;
• We can keep the instructions that would help customers to migrate from the old autokey module to this one;
• We provide an opinionated way for customers to interact with terraform resources using a module, like most of the Google services have;

Let me know what you think about that!
Also, I'm available to implement this proposed change, if you think it's a good idea.

Thanks!

[romanini-ciandt]

/gcbrun

[romanini-ciandt]

/gcbrun

[romanini-ciandt]

We should remove this comment block.

[nb-goog]

thanks done

[nb-goog]

Which version shall i use here? I think i need the version generated after this pr merged right?

[romanini-ciandt]

You should keep it as source = "../../modules/autokey". It's correct, we just can update it with a version number after the PR is merged and the next release is cut.

My comment here was just to remove the comment block, deleting the unused code, not to uncomment. We can update it later when we have a release.

[nb-goog]

Just for my own understanding, why is it better to keep google_kms_key_handle resource outside the terraform-google-kms module scope?

KMS has two personas

1. key admin
2. Key users (developers, etc

key admin should only focus on key management policies and setups AND shouldnt have access to kms keys created.
The keyhandle creation and access to keys is for second persona (key users) thats why we are separating it out

If the only motivation to cut google_kms_key_handle from KMS module is to handle the different personas, how about we implement a change that would accommodate that capability while still keep the benefits of the module?

Suggestion: we could turn google_kms_autokey_config creation optional when using autokey's submodule. google_kms_key_handle is already optional, based on user inputs. That way, key admins could use autokey's submodule passing the desired inputs to create just the Autokey Configuration, while key users could also use autokey's submodule but passing different inputs in order to just create the Key Handle.

To be more clear, the module's usage would be something like that:

# Key admins usage example
module "autokey" {
  source  = "terraform-google-modules/kms/google//modules/autokey"
  version = "3.1.0"

  project_id            = "project-bar"
  autokey_configuration_folder = "123456789"
  }
}

# Key users usage example
module "autokey" {
  source  = "terraform-google-modules/kms/google//modules/autokey"
  version = "3.1.0"

  autokey_handles = {
    storage_bucket = {
      name                   = "bucket-key-handle",
      project                = "project-foo",
      resource_type_selector = "storage.googleapis.com/Bucket",
      location               = "us-central1"
    },
    compute_disk = {
          name                   = "disk-key-handle",
          project                = "project-foo2",
          resource_type_selector = "compute.googleapis.com/Disk",
          location               = "us-central1"
    }
   # It would be possible to create multiple Key Handles here, if desired.
  }
}

Some benefits of using the KMS module approach:

• Customers (key users) could create multiple Key Handles using a single terraform module call;
• By using modules, customers could take leverage from "version", bringing more stability to their environments;
• We can keep the instructions that would help customers to migrate from the old autokey module to this one;
• We provide an opinionated way for customers to interact with terraform resources using a module, like most of the Google services have;

Let me know what you think about that! Also, I'm available to implement this proposed change, if you think it's a good idea.

Thanks!

See this makes a lot more sense if Security admin and Key admin are the same person.
There is clear guidance from the PMs and Autokey customers that configuration and key creation should be clearly separated..

Your suggestion makes sense but the expectation from the perspective of the personas are quite differnt.

[nb-goog]

/gcbrun

[romanini-ciandt]

/gcbrun

[romanini-ciandt]

/gcbrun