search

sysdiglabs / terraform-google-secure-for-cloud

Terraform module that deploys the Sysdig Secure For Cloud stack in Google Cloud Platform
https://registry.terraform.io/modules/sysdiglabs/secure-for-cloud/google/latest
Apache License 2.0
2 stars 11 forks source link

Add a random uuid suffix to workload identity pool ID #129

Closed airadier closed 1 year ago

airadier commented 1 year ago

We need reproducibility (ability to destroy and recreate) SFC for Google.

But we are hitting the known problem described in https://github.com/sysdiglabs/terraform-google-secure-for-cloud#q-getting-error-creating-workloadidentit[…]error-409-requested-entity-already-exists, so we need to manually undelete and import the workload identity pool every time.

This adds an uuid suffix to the identity pool ID and provider ID to make sure a new one is created everytime

nkraemer-sysdig commented 1 year ago

I agree this is a pain point, however this alone won't be sufficient. In order to use Workload Identity Federation to retrieve a temporary token, the Sysdig backend needs to make a request to this specific WIF pool. This URL is currently built using the projectID, however it always uses sysdig as the pool ID. In order to support dynamic poolIDs, this information needs to be sent to the backend, persisted, and passed along to all consumers.

wideawakening commented 1 year ago

thanks for confirming Noah, it was long ago this was raised in #44

airadier commented 1 year ago

Would it be possible to add an option to use an existing workload identity pool (i.e. a data instead of resource)?

Automating the undelete and import is complex, because we are using Terraform Cloud and all the credentials are stored in there. Any external automation that needs to undelete and import requires replicating all the credentials outside Terraform Cloud.

There is not much automation we can do inside Terraform Cloud inside except Terraform code. Using a Terraform provisioner won't work because we can run the "undelete" command but we won't be able to import something to the state while Terraform is running, as the state will be locked.

A middle ground approach could be to allow an option to retrieve the pool via data instead of creating a new one via resource, and we could create a provisioner that runs before the SFC Google module (making the module dependent on the provisioner) to make sure the pool is undeleted, and then it can be reused.

Does it make sense? I can try making the change on this PR.

airadier commented 1 year ago

See alternative implementation, via an option to reuse existing workload identity pool: https://github.com/sysdiglabs/terraform-google-secure-for-cloud/pull/130