terraform-provider-azuread
terraform-provider-azuread copied to clipboard
fixed #1031 adds provision on demand
Hey @manicminer,
I have tested this with an AWS SSO configured app and it worked well, however I don't have access to an Azure tenant I can test the providers functional tests on. Not sure how best to proceed atm.
Terraform will perform the following actions:
# azuread_synchronization_job_provision_on_demand.example will be created
+ resource "azuread_synchronization_job_provision_on_demand" "example" {
+ id = (known after apply)
+ job_id = "aWSSingleSignon.hidden"
+ service_principal_id = "hidden"
+ parameters {
+ rule_id = "hidden"
+ subjects {
+ object_id = "hidden"
+ object_type_name = "Group"
}
}
}
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
azuread_synchronization_job_provision_on_demand.example: Creating...
azuread_synchronization_job_provision_on_demand.example: Creation complete after 4s [id=d66c068e-2711-409e-068d-8b55b8bb852e]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
Contains existing PR changes for reference only, will rebase once they are merged.
hey @manicminer, thanks for the feedback. I have addressed all the parts you raised. For the acceptance test i'd need to know what the rule_id are available in the databricks schema in order for it to run. We could also do with a data source for this, but didnt see it in the graph api lib - https://learn.microsoft.com/en-us/graph/api/synchronization-synchronizationschema-get?view=graph-rest-beta&tabs=http
@manicminer is there anything further I can do to help with this?
@iwarapter Thanks, and apologies for the delayed reply. At this time I don't have the bandwidth to create tests for this, so if you could have a go at writing some acceptance tests that will help enormously. I don't mind kicking the tires and tweaking existing tests to get them working reliably, but this will be waiting a little while if I have to write the tests. Thanks!
hey @manicminer i had a quick stab - https://github.com/iwarapter/terraform-provider-azuread/commit/9da78c0ed05382143b0e90ee0cce37b1b143c576 there are a few //TODO which i need extra info for
@manicminer have pushed the tests - from what i can see the databricks integration used for acctests isnt fully integrated so this can't be tested e2e with it (im just testing config and then the expected failure). is there another app the acctests can use to test full e2e provisioning?
Hi @manicminer, thanks for getting back to this. Thats correct, but there is prior art for this style of resource - mainly the aws lambda invocation resource.
The only way you could check if the resource has been provisioned currently is by calling the provision api and checking the response code - but this is definitely not what we want in the READ part 😄. I certainly wouldn't bundle this into any other resources as the closest one is the azuread_synchronization_job.
I disagree that it's not a good fit for terraform as it enables a key part of fully managing resources across azuread and a given service provider. Here's a quick example use case:
Add a group to a azure application (all covered with this provider) GAP Assign a SCIM managed group to a given permission set within AWS (all covered with the AWS provider)
This resource solves the gap between the two where the group won't exist in AWS as you at the mercy of the SCIM scheduler. I deploy many hundreds of groups/role bindings and this is quite painful.
@iwarapter Thanks for the context, I see now that the sync can happen in either direction and the resulting object(s) are not likely to be directly managed anyway. In which case this seems like a reasonable way to implement this. Do you think it's worth adding a triggers faux-meta argument (which is conventionally a map) to enable programmatic reprovisioning?
its not a bad shout, i cant think of any (personal) use cases for it. But simple enough to just add a map trigger
I'll try add this tomorrow morning
@manicminer lifted straight from the aws provider 😂
cool glad to see this getting merged :)
Test result