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]

/autokey-setup and /keyhandle-setup examples are not being executed by CI because of the current folder structure (examples/autokey/autokey_...).
The blueprint-test framework expect the examples to be directly behind examples/ folder. (At least using default configs. It's possible to override that with some changes in test files. Here's a reference.)

[nb-goog]

thanks for the info :)

moved the folders inside /examples directly and gave them relevant name.
Please take a look

[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!

[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]

This example won't be successfully applied in CI since it's missing the Autokey configuration resource in this file.

For blueprint-test, each example is applied individually and must be successful applied in order to pass.

[romanini-ciandt]

/gcbrun