The Platform Mesh account model maps organization structure to isolated control-plane spaces.
Accounts are the Platform Mesh concept users interact with. kcp workspaces are the backing control-plane mechanism that gives each account its own API surface and authorization boundary.
flowchart TB
org[Organization]
teamA[Team A]
staging[Staging]
prod[Production]
dev[Development]
teamB[Team B]
qa[QA]
org --> teamA
teamA --> staging
staging --> prod
teamA --> dev
org --> teamB
teamB --> qa
The hierarchy lets organizations model teams, projects, and environments without creating a physical Kubernetes cluster for every boundary.
Platform Mesh can use accounts to represent several roles:
| Role | Purpose |
|---|---|
| Organization | Top-level tenant or business boundary |
| Team or project | Internal ownership boundary inside an organization |
| Environment | Development, staging, production, or other lifecycle boundary |
| Provider | Space where service provider APIs and automation are managed |
| Consumer | Space where users bind and consume provider APIs |
The exact account types available in an installation depend on the Platform Mesh version and account operator configuration.
Accounts provide:
Provider and consumer accounts stay isolated. A provider exposes a declarative API; a consumer binds that API into its own account workspace. Platform Mesh mediates the relationship through kcp, identity, authorization, and account lifecycle automation.
Account lifecycle is tied to identity and authorization state. Keycloak provides authentication. OpenFGA stores relationship-based authorization state. Platform Mesh components wire those systems to account and workspace lifecycle.