Platform Mesh

Security architecture

Securing a distributed, multi-tenant platform that spans organizational boundaries requires a deliberate architectural approach. Traditional monolithic security models, where authentication and authorization are tightly coupled within a single system, fail to address the dynamic nature of service ecosystems where service providers, service consumers, and marketplace operators interact across isolated control planes.

Platform Mesh addresses this challenge through a clear separation of authentication and authorization as independent architectural concerns, each implemented by purpose-built components that can evolve, scale, and be replaced independently. This design aligns directly with the decoupling principle that guides the overall architecture: security subsystems, like all other components, should be directly usable without requiring the complete framework.

For the runtime view — which component plays which role and how requests pass through the authorizer chain — see Identity and authorization.

Client entry paths

Platform Mesh is accessed through multiple client types, each with distinct interaction patterns. UI clients interact through a Kubernetes-GraphQL-Gateway, kubectl users communicate directly with kcp via the KRM API, and AI agents are expected to interact through a dedicated MCP (Model Context Protocol) server¹. Regardless of the client type, all requests ultimately reach kcp, where the same authentication and authorization mechanisms apply uniformly.

flowchart LR
    UI[UI Client] --> GW[GraphQL Gateway]
    CLI[kubectl] --> KCP
    GW --> KCP[kcp]
    AI[AI Client] -.-> MCP["MCP Server (planned)"]
    MCP -.-> KCP

    style MCP stroke-dasharray: 5 5
    style AI stroke-dasharray: 5 5

Authentication and authorization flow

Once a request reaches kcp, the authentication configuration establishes the caller’s identity, and a layered authorizer chain decides whether the request is allowed. RBAC handles structural, resource-type access; the authorization webhook forwards anything RBAC has no opinion on to OpenFGA for relationship-based evaluation.

flowchart TD
    KCP[kcp] --> AUTHN[AuthN Config]
    AUTHN -->|OIDC| KC[Keycloak]
    AUTHN --> SA[ServiceAccounts]
    KC -->|identity established| RBAC[RBAC]
    SA -->|identity established| RBAC
    RBAC -->|granted| RES[Access Granted]
    RBAC -->|denied| DENY[Access Denied]
    RBAC -->|no opinion| WH[AuthZ Webhook]
    WH -->|check| FGA[OpenFGA]
    FGA -->|granted| RES
    FGA -->|denied| DENY

Separation of concerns

Authentication and authorization are independent subsystems, reflecting Platform Mesh guiding principles. The two are connected solely through the OIDC token: authentication produces it, authorization consumes the identity claims within it. While OIDC tokens carry claims such as group memberships that inform RBAC decisions, the token should establish who the caller is, not what they are allowed to do — encoding permissions as group claims is an anti-pattern that blurs this boundary. They share no other state, meaning each can evolve, scale, and be replaced independently. Both are integrated through standard Kubernetes extension points (authentication configurations for identity providers and authorization webhooks for authorizers), enabling alternative implementations that satisfy the same interfaces.

However, Platform Mesh provides specific integration with Keycloak and OpenFGA, such as per-organization realm and store provisioning, identity brokering configuration, and dynamic authorization schema generation. Replacing either component with an alternative would require reimplementing these integration aspects.

:::info NOTE Platform Mesh security architecture represents ongoing research in distributed authorization patterns. The model continues to evolve to support enhanced cross-provider authorization scenarios, relationship-based authorization model management, and advanced authorization propagation across the account hierarchy. :::

Platform Mesh security architecture builds on kcp’s own security foundations, including workspace isolation, APIExport identity, and permission claims. For a detailed analysis of these foundations, see the kcp Security Self-Assessment (particularly the Security Functions and Features section) and the security section of kcp’s General Technical Review.

Security and the account model

The security architecture integrates deeply with the Platform Mesh account model, ensuring that security boundaries align with organizational boundaries throughout the hierarchy.

Per-organization identity realm: Platform Mesh creates a dedicated Keycloak realm for each organization, providing complete isolation of user stores, client configurations, and authentication policies. This realm is configured as an OIDC provider through kcp’s authentication configuration, tying the organization’s identity management directly to its account hierarchy.
Per-organization FGA store: Similarly, each organization receives a dedicated OpenFGA store, isolating authorization state across organizational boundaries. This ensures that relationship tuples and authorization evaluations for one organization cannot interfere with another.
Dynamic authorization schema: Platform Mesh dynamically generates the OpenFGA authorization schema for each organization based on the APIs bound within that organization’s accounts. As service providers expose new capabilities and consumers bind to them, the authorization model automatically evolves to include the corresponding types and relations, eliminating the need for manual schema maintenance.
Hierarchical inheritance: OpenFGA relationship tuples can be inherited through the account hierarchy. Permissions defined at a parent account can propagate to child accounts through the relationship graph, simplifying governance while allowing overrides where organizational requirements demand it.
Service-relationship authorization: When service consumers engage with service providers through the export and bind mechanisms of the account model, the authorization layer automatically reflects these relationships. OpenFGA also controls where in the account hierarchy a provider’s service can be bound, ensuring that service consumption is constrained to the appropriate organizational scope.
Marketplace integration: When a provider API is activated through a marketplace, the OpenFGA authorization schema for the organization is extended to include the corresponding resource types and relations, making the new service’s resources available for fine-grained authorization decisions.

Authentication — design view of how identity is established
Authorization — design view of layered RBAC + ReBAC decisions
Identity and authorization — runtime view of the same components
Account model — organizational hierarchy that frames per-org isolation

The MCP server for Platform Mesh is a planned future component. ↩

This site is open source. Improve this page.