Posted our module to the internal repo. Automates mobile user config deployment for Prisma Access across multiple regions.
Key features:
* Provisions Mobile Users Configuration and Bandwidth Allocation via `prismacloud_policy_rules`.
* Handles service connection and remote network dependencies.
* Uses variable files for region-specific settings.
Example variable structure:
```hjson
region_config = {
"eu-west-1" = {
bandwidth_total = 5000
spn_name = "EU-Service-Connection"
}
}
```
Main module block:
```terraform
module "prisma_mobile_users" {
source = "./modules/prisma-mobile-users"
regions = var.region_config
template_profile = "default-mobile-users"
}
```
Ran it against our dev tenant. Initial `terraform plan` output showed 12 resources to add. Execution time was 4 minutes 22 seconds.
Observations:
* The `prismacloud` provider's `mobile_users` resource is still limited. Had to use composite policy rules.
* Bandwidth allocation changes sometimes require a second apply.
Has anyone else automated this? Specifically interested in:
* Handling of dynamic SPN lists.
* State management for multi-tenant deployments.
-bench_beast
Benchmarks don't lie.
Nice work. I hit that second apply for bandwidth too - seems like the provider needs a moment to sync. For dynamic SPNs, I ended up with a data block feeding a for_each that builds the list from tags. Keeps it from breaking when infra team adds new ones.
State across tenants: we used a backend key with workspace name interpolation. Still feels messy though. How'd you handle the remote network dependency ordering? I've had that timeout a couple times.
Nice, that's similar to our setup. That second apply for bandwidth changes is a known quirk, the provider docs mention it briefly.
For state across tenants, we've been using a mix of workspaces and partial backend config in CI. It's okay, but I'm not in love with it either. Did you consider using `terraform_remote_state` data sources for cross-tenant dependencies, or is that too much coupling?
measure twice, ship once
4m22s is too slow for iterative work. That's a pipeline killer.
> Bandwidth allocation changes sometimes require a second apply.
The provider quirk is real. I've seen it too. I script around it now: `plan` > `apply` > `plan` and only proceed if the second plan is empty. If it isn't, auto-run the second apply. Annoying, but it unblocks CI.
For dynamic SPNs, a `for_each` on a data source is the way. Don't bake names into your module variables; it'll break. Fetch them by tag via data.
Multi-tenant state: separate workspaces with separate backends. Keep them isolated. Using `terraform_remote_state` creates a hard dependency that'll bite you during outages. I use a slim pipeline that runs the same module against each tenant workspace sequentially. State stays separate, blast radius is contained.
Yeah, the double apply quirk is a real pain for automation. Your script approach is smart. I ended up doing something similar in our GitLab CI, but added a timeout and a retry limit so it doesn't loop forever if something's actually broken.
> separate workspaces with separate backends
Totally agree on the isolation. We tried the `terraform_remote_state` approach once and it created a fragile web. Now we just use a pipeline matrix to run against each tenant independently. The state files never talk to each other. It's a bit more code in the pipeline YAML, but way safer when a single tenant API is having a bad day.
Infrastructure as code is the only way