Rotate & offboard

Credential rotation and clean removal, per cloud. No long-lived cloud credentials by default: the Azure client-secret fallback is the exception, and it expires 90 days after creation. Rotate the AWS external ID and review Google Cloud and Azure federation subjects at least every 12 months, and rotate sooner after personnel, issuer, subject, or compromise events. Every change pairs terraform apply or terraform destroy with the matching action in Integrations / <Connector name>.

Venturi API keys and SaaS connector credentials stay valid until you rotate them. Rotate API keys at Settings / Admin / Credentials. Rotate a SaaS connector credential with its vendor, then update the credential reference in Venturi.

Rotate

AWS: external_idGoogle Cloud: federation subjectsAzure: federated subjectAzure: client-secret fallback

The trust policy accepts a single external ID, and terraform apply replaces it in place, so rotation is a coordinated cutover. Old and new values are never accepted at the same time.

1. In Integrations / AWS, generate the next external ID. The current value stays active.
2. Set external_id in terraform.tfvars to the new value, then run terraform plan and terraform apply. The role now rejects the previous value for new sessions; sessions issued before the apply keep working until they expire, at most 15 minutes later.
3. Immediately activate the new value in the connector settings and rerun automated credential validation. Until you activate the new value, Venturi cannot start new sessions, so complete steps 2 and 3 together.
4. If validation fails, confirm that terraform.tfvars holds exactly the activated value, apply again, and rerun validation.

wif_allowed_subjects is a list, so rotate with no downtime:

1. In Integrations / Google Cloud, generate the next exact subject.
2. Add it to wif_allowed_subjects, keeping the current subject, and run terraform apply. Both subjects are now accepted.
3. Activate the new subject in the connector settings and rerun automated credential validation.
4. Remove the previous subject and run terraform apply again.

Do not use wildcards to bridge rotation.

The module models a single federated identity credential, so subject or issuer rotation is a coordinated cutover.

1. In Integrations / Azure, generate the next exact subject, and issuer if it changes.
2. Set federated_credential_subject and federated_credential_issuer in terraform.tfvars, then run terraform plan and terraform apply. The credential now accepts only the new values.
3. Immediately activate the new values in the connector settings and rerun automated credential validation. Venturi cannot exchange tokens between the apply and this step, so complete them together.

The fallback secret expires 90 days after creation, and the module keeps a single secret, so renew it before that date as a coordinated cutover. Run these commands from infra/azure/onboarding with the state you applied:

Bash

CLIENT_ID="$(terraform output -raw client_id)"
az ad app credential list --id "$CLIENT_ID" --query "[].endDateTime" --output tsv
terraform apply -replace="$(terraform state list | grep '^azuread_application_password\.')"

1. The az command prints the current secret’s end date.
2. The -replace apply deletes the current secret and then creates a new one that is valid for 90 days. Terraform stores the new value in plain text in the state file.
3. Read the new value with the command in Client-secret fallback and enter it in the Azure connector step of guided setup, which stores it as an encrypted credential reference. Venturi cannot obtain tokens between the apply and this step, so complete them together.
4. Rerun automated credential validation.

Offboard (remove access)

Disable the connector first

Disable the connector in Integrations / <Connector name> before you destroy, so attribution ingestion stops cleanly rather than failing mid-read.

Run terraform destroy from the extracted module directory that you applied during setup, with its terraform.tfvars and Terraform state or backend configuration. Set CLOUD to aws, gcp, or azure, then run:

Bash

CLOUD="aws"
cd "infra/$CLOUD/onboarding"
terraform destroy

This removes everything the module created:

Cloud	Destroyed
AWS	The IAM role and its policies
Google Cloud	The service account, the Workload Identity Pool and provider, and all IAM bindings
Azure	The app registration, the service principal, the federated credential or client secret, and all role assignments

On AWS, IAM evaluates a session’s permissions on every request, so new assume-role calls and requests from existing sessions fail once IAM propagates the deletion, which can take a few minutes. No Venturi session outlives its 15-minute duration in any case. On Google Cloud and Azure, access ends once the provider propagates the deletion and any access token already issued expires.

Audit trail

Keep the granted_permissions output (AWS) or granted_roles output (Google Cloud and Azure) from your original terraform apply. It is a summary of what the module granted; the module source and the applied plan are the exact record. Keep all three for a security review.

After any rotation, rerun automated credential validation and the customer-run check for that cloud in Verify & confirm, and retain its output with the Terraform plan and apply record.

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details

Docs feedback: Rotate & offboard
Page: https://docs.venturi.systems/reference/rotation/