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?

[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

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

[romanini-ciandt]

/gcbrun

[romanini-ciandt]

/gcbrun

[tdbhacks]

This LGTM, I'll defer to:

• @romanini-ciandt to do one last pass and approve
• the CFT team re: breaking change, I believe Leo will be summarizing the changes and looping them in, so they're aware and can give final approval.

[romanini-ciandt]

The terraform code looks good, I just can't evaluate the decisions made in order to generate this breaking change.

As @tdbhacks mentioned, I'll summarize the changes and involve CFT team so they can give the final approval.

[apeabody]

Thanks @tdbhacks @romanini-ciandt!

Thanks @nb-goog - For the breaking change, I recommend including a public docs/upgrading_to_v4.0.md transition guide. Here is an example from another repo: https://github.com/terraform-google-modules/terraform-google-kubernetes-engine/blob/master/docs/upgrading_to_v33.0.md. In particular it looks like current users of the autokey module will need to switch project_id to autokey_kms_project_id?

[nb-goog]

Thanks @tdbhacks @romanini-ciandt!

Thanks @nb-goog - For the breaking change, I recommend including a public docs/upgrading_to_v4.0.md transition guide. Here is an example from another repo: https://github.com/terraform-google-modules/terraform-google-kubernetes-engine/blob/master/docs/upgrading_to_v33.0.md. In particular it looks like current users of the autokey module will need to switch project_id to autokey_kms_project_id?

done

[erlanderlo]

a design/usability question to ponder

[romanini-ciandt]

/gcbrun

[romanini-ciandt]

/gcbrun

[apeabody]

/gcbrun

[nb-goog]

/gcbrun

[romanini-ciandt]

/gcbrun