Multi-tenant Strata Cloud Manager
Tenant hierarchy, naming standard and identity plane for a large healthcare enterprise that keeps acquiring companies it cannot fully absorb.
--- title: "Multi-tenant Strata Cloud Manager" summary: "Tenant hierarchy, naming standard and identity plane for a large healthc…" stack: ["Strata Cloud Manager", "Prisma Access", "Prisma SD-WAN"] relevance: "Hierarchy keyed to who manages, not where." featured: true section: work ---
Problem
A large healthcare enterprise — call it Globex — with several operating entities, an acquisition roughly every year, and no single answer to who runs the network of any given one of them. Some acquisitions are run by Globex IT from the first week. Some stay on the managed service provider that was already operating them, for years, under a contract Globex inherited. A platform group wants its own Prisma Access and NGFW footprint with no blast radius into production. All of it is managed from Strata Cloud Manager, and the tenant tree is the thing that decides who can change what.
The first two instincts for shaping that tree are geography and the org chart. Both fail the same way. A region contains a mix of operators, so a regional tenant has to be administered by all of them, which is the boundary the tree was supposed to draw. A business unit reorganizes, and a tenant named after it is either renamed or left as a fossil. The one question with a stable answer is who operates the stack on day two. The hierarchy is keyed to that and nothing else.
The root tenant holds licensing, publishes the snippets every child must carry, owns posture, and shares its Cloud Identity Engine down the tree. It has no device folders and no runtime stack: nothing in production terminates at the root, so no root change can take a site down. Each child carries the services its entity actually uses — Prisma Access, Prisma SD-WAN, NGFW, or any subset — and nothing it does not.
An acquisition lands in one of two shapes. Absorbed, like BetaCo, it is an IT_ child under the root with no children of its own, operated by Globex IT from the start. Provider-managed, like AcmeCo, it is an MSP_ sub-parent: the provider's administrators are scoped to that node and the regional children beneath it, and they never see a Globex child.
Naming standard
Every tenant below the root is named ORG_<IT|MSP|DEV>_<entity|region>. The
middle token answers one question — who operates it — and is the only thing the
name encodes.
- IT_ — operated by Globex IT. Full service stack, change control through Globex's own process, root-published snippets attached on day one.
- MSP_ — operated by a third party under contract. Always a sub-parent, even with a single child, so the provider's scope has a node to bind to that is not the leaf carrying production. Globex retains governance at the root and nothing below it.
- DEV_ — engineering and lab. Carries the posture baseline and nothing else from the root, holds no production, and can be deleted without anyone outside the platform group noticing.
The last token is the entity when one tenant covers it, and the region once an
entity's footprint has to split: ORG_IT_Globex-NA and ORG_IT_Globex-EU are
two children because they are two change windows, two sets of on-call
engineers and two regulatory scopes, not because a map says so. A tenant is
renamed for exactly one reason: its operator changed. A reorganization that
moves a business unit between executives changes nothing in the tree, because
the tree never recorded the executive.
Administrative access is one Entra group per archetype, mapped to one role at one scope. Root governance is a superuser scoped to the root. A child operator is a superuser scoped to that child and nothing above it. The provider's NOC is a multitenant role scoped to the MSP_ sub-parent, which carries to the regional children beneath it. Audit is read-only across the tree. Access is granted by adding someone to a group in their own directory; the console is never where authority is edited.
The Cloud Identity Engine is in the figure because it is the thing most often mistaken for the admin plane. It is shared from the root so that every child's policy can reference the same users and groups, and that is all it is: a User-ID source. Membership in a synced group puts a user into a security rule. It never puts them into the console.
00 ORG_IT_Globex-NA tenant · child of root 01 ├─ Prisma Access 02 │ ├─ Mobile Users 03 │ └─ Remote Networks 04 ├─ NGFW 05 │ ├─ dc-atl device folder 06 │ ├─ dc-dal device folder 07 │ └─ azure-hub Cloud NGFW · case 04 08 └─ Prisma SD-WAN 09 0a snippets 0b ├─ [root] posture-baseline read-only here 0c ├─ [root] logging-and-decryption read-only here 0d ├─ [root] admin-rules-pre read-only here 0e ├─ [local] na-app-allowlist editable here 0f └─ [local] na-site-exceptions editable here
Authored at the root and published to the child. They carry the rules that apply everywhere and are not editable below the root; a child administrator sees them and cannot change them.
The child’s own. Attached to folders inside this tenant only, so a rule written here cannot reach a sibling.
Nothing flows from root to child by default. Each root snippet is deliberately published to each child, which makes the baseline a reviewable list rather than an inheritance.
The Cloud NGFW for Azure hub in case 04 is one device folder here: its policy is this child’s, beneath the root baseline.
The folder hierarchy inside a child mirrors the trust boundary, not the network topology, because the hierarchy is what determines who can change what. Rules that apply everywhere are written once at the root, published to every child, and are not editable below. Tenant-specific rules live in that tenant's own snippets and folders and cannot reach across to a sibling. A child administrator's authority ends at their own boundary as a structural property rather than as a convention, and the root's baseline is a list of explicit publications rather than something that happened on its own.
Landing an acquisition
| Decision | IT_ absorbed child — BetaCo | MSP_ sub-parent — AcmeCo |
|---|---|---|
| Who operates on day two | Globex IT | The incumbent provider, under the inherited contract |
| Shape in the tree | One child under the root, no children of its own | A sub-parent with one child per region it serves |
| Licensing | Root | Root; the provider never holds a license |
| Admin identity | Globex Entra groups mapped to roles scoped to the child | The provider's own Entra groups, scoped to the MSP_ subtree; Globex keeps root governance only |
| User-ID | Cloud Identity Engine shared from the root | Shared from the root; the provider's directory may be added per child |
| Policy baseline | Every root-published snippet attached on day one | Posture baseline from the root; everything else is the provider's local snippets |
| Exit | Folded into an existing IT_ regional child once the networks merge | Re-homed as IT_ when the contract ends — a rename and a scope change, not a rebuild |
The row that decides the column is the first one. Everything beneath it is a consequence of who answers the phone when a site goes down, and that answer is in the contract before the tenant exists.
Verified and assumed
| Claim | Status | Consequence for the design |
|---|---|---|
| Administrative authority is bounded by role scope in the tenant tree, not by PAN-OS-style access domains | Verified | Scopes are the boundary; there is no second mechanism to keep in sync |
| The Cloud Identity Engine is a User-ID source, not an administrator provisioning path | Verified | Sharing it tree-wide grants nobody console access; admin IAM is groups and scopes only |
| No root-to-child policy inheritance happens on its own; root snippets must be published to each child | Verified | The baseline is an explicit, reviewable list per child, and a new child starts empty |
| A tenant's place in the tree does not set data residency; residency follows the region the tenant was provisioned in | Verified | Regional children exist for operations and scope, not for residency, which is fixed at creation |
| An MSP_ sub-parent can be re-homed as IT_ by renaming and re-scoping, without re-provisioning its children | Assumed | The exit row above depends on it; the fallback is a migration into a fresh IT_ child |
| Two levels of nesting cover every acquisition shape Globex will see | Assumed | A provider that itself subcontracts a region would need a third level, which has not been tested |
| Precedence between root-published and local rules is pinned by snippet order in every child | Assumed | Each child's ordering is set at creation and reviewed on every root publication |
What I'd change
The naming standard records the operator and nothing else, which is its strength, and it also means an absorbed entity three weeks into migration looks identical to one that finished a year ago. A lifecycle token or a tag for transition state would have saved a recurring conversation.
The Cloud Identity Engine is shared from the root to the whole tree. For IT_ children that is correct. For an MSP_ subtree a directory boundary at the sub-parent would be cleaner, so the provider's regional children reference the provider's users without the root having to know them.
The publish order of root snippets was documented after the first child existed. It should have been pinned before, as part of creating the root, because every later child inherited whatever order the first one happened to get.
DEV_ as an archetype earned its keep. As a child of the production root it still shares licensing and posture with production, and a lab that needs neither would be better as a tenant of its own.
The hub in Azure cross-tenant Cloud NGFW hub is
the Azure consumer of one IT_ child: its Cloud NGFW is the azure-hub device
folder under ORG_IT_Globex-NA, and its policy is that child's local snippets
beneath the root-published baseline.
The folder-versus-scope distinction this tree leans on is written up on its own in Folders are structure, scope is authority.