-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add allowed_account_id
provider configuration parameter
#226
Add allowed_account_id
provider configuration parameter
#226
Conversation
@swgillespie Hi again! Wanted to ping you on this. We are running our Pulumi provider off of a fork of this repo that contains this change (and have been for some time); once this is in I can move the Pulumi provider off of the fork and make it public! |
Hi @ennyjfrick thanks for submitting this, i think it's a great idea. I'm wondering if you'd mind adding a test for this behavior in |
Hey @briankassouf, I originally wrote an acceptance test for it but since it throws an error when calling The AWS provider handles this by setting up a bunch of mocks for the STS service endpoints; I am not aware of any existing similar mocks for |
@ennyjfrick I haven't used it before so I'm not certain, but I wonder if TestCase.ErrorCheck will let you ignore the error on destroy?
If we can't get it to work with the acceptance testing framework then that's ok, we can revisit adding a mocked backend at a later date. |
@briankassouf hmm, doesn't look like we can make setting
|
Ok, thank you for trying! |
6c5153b
to
917c958
Compare
What was changed
This PR adds a new optional provider configuration parameter,
allowed_account_id
, that, when set, prevents operations against accounts that do not have the same ID as that provided.Why?
My org has a separate Temporal Cloud account for our development environment that we manage using IaC; currently, it is incredibly easy to accidentally operate on the wrong Temporal Cloud account by having the wrong API key active in our environment and has caused cross-contamination between our dev environment and staging/production environments. The AWS Terraform provider allows you to prevent this by providing an
allowed_account_ids
configuration parameter (implementation here), which we use for our AWS resources. This provides a similar functionality.Checklist
1. Closes n/a
2. How was this tested:
This unfortunately needs to be tested manually (since the post-acceptance test delete returns an (expected) error). at a later date we might want to consider generating some mocks to fully test the provider configuration.
Test steps:
main.tf
with the following, replacingACCOUNT_ID
with the appropriate account ID:terraform init && terraform apply
main.tf
to match the following:terraform init && terraform apply
again3. Any docs updates needed?
Docs generated!