adwittumuluri
commented
1 year ago Hey evan, here is where we Acquire a cloud provider account by ID. Seems like that's plumbed all the way through to the admin console, and can be set via the admin-cli.
admin-cli cluster create [other args] --account-id [account id]Seems like we're very vocal in the comments that it's for testing purposes, though if it makes the TF flow a lot easier, then we can argue against that.
marksoper
This commit adds a new CMEK resource, which primarily manages the configuration of customer-managed encryption keys (CMEK). CMEK is enabled for a cluster when the resource is created, and keys can be rotated by updating their specs.
Due to circular dependencies (new regions depend on CMEK config, which depends on role policy, which depends on cluster), new regions must be managed by the CMEK resource. That means the cluster resource and CMEK resource need to keep track of which regions they "own" and reconcile that with updates and the actual state of the cluster. That's the bulk of the complexity here.
Destroying a CMEK resource is a no-op, since CMEK cannot be disabled. That means that a user could be left with "floating" regions. I need to figure out a way to block targeted destroy operations on CMEK resources while allowing them to be removed from state when the parent cluster is destroyed. We could attempt to remove additional regions on destroy, but that would take significantly longer.
Happy to do a walkthrough and discuss tradeoffs at a watercooler.
Add a description of the problem this PR addresses and an overview of how this PR works.
This change is