Security

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 providersA service provider offers services to consumers., service consumersAn organization or individual that orders, utilizes, and manages the lifecycle of a service., and marketplace operators interact across isolated control planesCentral management system responsible for orchestrating and managing a target environment..

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.

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 kcp An open source horizontally scalable control plane for Kubernetes-like APIs. via the KRM API, and AI agents are expected to interact through a dedicated MCP (Model Context Protocol) server^[1]. Regardless of the client type, all requests ultimately reach kcp kcp An open source horizontally scalable control plane for Kubernetes-like APIs., where the same authentication and authorization mechanisms apply uniformly.

Authentication

Authentication in Platform Mesh establishes a verified identity for every interaction, whether initiated by a human user, an automated pipeline, or a service-to-service call. The platform standardizes on OpenID Connect (OIDC) as the primary authentication protocol, providing a consistent, token-based identity layer across all participants in the mesh. In addition, kcp kcp An open source horizontally scalable control plane for Kubernetes-like APIs. natively supports Kubernetes service accounts, enabling workloads and automation to authenticate directly without requiring an external identity provider.

Keycloak is configured as an OIDC provider through kcp kcp An open source horizontally scalable control plane for Kubernetes-like APIs.'s authentication configuration mechanism, the same declarative approach used to configure any OIDC-compatible identity provider. For user-facing identity providers, Keycloak acts as the federation layer through its identity brokering mechanism. For machine identity issuers, such as Kubernetes cluster JWT issuers or GitHub Actions OIDC, where identity brokering through Keycloak does not apply, kcp kcp An open source horizontally scalable control plane for Kubernetes-like APIs.'s support for OIDC configuration at the workspace level enables direct integration at the account level. This ensures that the authentication layer is not hardwired to a single provider or federation path but rather configured through standard Kubernetes primitives.

Internal Identity Provider

Keycloak^[2] serves as the internal Identity Provider (IDP) within Platform Mesh and Apeiro. As a centralized identity and access management solution implementing OIDC, OAuth 2.0, and SAML 2.0, Keycloak provides the authentication surface through which all platform interactions are verified.

Key aspects of Keycloak's role within Platform Mesh:

• Token-Based Identity: Keycloak issues JWT-based access tokens, ID tokens, and refresh tokens following OIDC standards. These tokens carry identity claims that downstream services consume to establish the caller's identity without repeated authentication.
• Authentication Flows: Platform Mesh leverages Keycloak's support for standard OIDC flows. The portal uses the Authorization Code grant for interactive browser sessions, while kubectl uses the Authorization Code grant with PKCE (Proof Key for Code Exchange) as a public client against kcp kcp An open source horizontally scalable control plane for Kubernetes-like APIs..
• Tenant-Aligned Realms: Platform Mesh creates a dedicated Keycloak realm per organization, providing isolated user stores, client configurations, and authentication policies that align with the hierarchical account modelA hierarchical structure that serves as the foundational fabric for managing interactions between service providers and consumers, enabling sophisticated service management while maintaining clear organizational boundaries and operational control..

Identity Federation

A critical requirement for any platform operating across organizational boundaries is the ability to integrate with existing identity infrastructure. As noted in the Operator Perspective, Apeiro supports connecting one or more OpenID Connect-compatible identity providers but does not prescribe a single provider.

Keycloak addresses this through its identity brokering mechanism. External identity providers (corporate OIDC providers, SAML identity providers, LDAP directories) can be connected as federated sources. Users authenticate against their existing corporate IDP, and Keycloak translates the external identity into a consistent internal representation, ensuring that downstream authorization decisions operate on a normalized identity regardless of the authentication source.

This approach enables the "bring your own IDP" model essential for multi-organizational service ecosystems while maintaining a uniform authentication contract across the mesh.

Authorization

Once an identity is established, Platform Mesh must determine what that identity is permitted to do. Given the complexity of interactions across hierarchical accounts, service providersA service provider offers services to consumers., and service consumersAn organization or individual that orders, utilizes, and manages the lifecycle of a service., Platform Mesh supports a two-tier authorization model: Kubernetes RBAC for control-plane-local decisions and OpenFGA for authorization across control plane boundaries.

Kubernetes-Native RBAC

The first tier leverages the built-in Role-Based Access Control^[3] mechanism of Kubernetes. Since the Platform Mesh API layer is built on the Kubernetes Resource ModelA framework used in Kubernetes to define and manage the various entities or resources. and powered by kcp kcp An open source horizontally scalable control plane for Kubernetes-like APIs., RBAC is the natural structural access control layer.

Kubernetes RBAC operates at the API resource level, governing which subjects (users, groups, service accounts) can perform which verbs (get, list, create, update, delete) on which resource types within a given workspace. Each account functions as an isolated control planeCentral management system responsible for orchestrating and managing a target environment. with its own RBAC configuration, meaning access policies are always scoped to the control plane they are defined in. RBAC rules are themselves Kubernetes resources, managed declaratively through the same KRM patterns used for all platform resources, consistent with the declarative API principle. This extends naturally to Custom Resource Definitions introduced by Managed Service ProvidersA service provider offers services to consumers.: when a service provider exposes new capabilitiesA concrete incarnation of a service that has been created and configured for a specific application or service., the existing RBAC mechanism governs access without additional configuration.

Fine-Grained Authorization with ReBAC

The second tier addresses authorization decisions that go beyond what RBAC can express: decisions that depend on relationships between entities such as team memberships, resource ownership, or service subscriptions.

OpenFGA^[4] provides Relationship-Based Access Control (ReBAC), an authorization model based on the Zanzibar approach^[5], where access decisions are derived from a graph of relationships rather than static role assignments. Authorization state is expressed as relationship tuples, (user, relation, object), and permissions propagate through the graph. For example, if a team has ordered a service and a user is a member of that team, the user inherits access to that service instance without explicit per-user permission grants.

The hierarchical account modelA hierarchical structure that serves as the foundational fabric for managing interactions between service providers and consumers, enabling sophisticated service management while maintaining clear organizational boundaries and operational control. maps naturally to this relationship graph, and permissions defined at a parent account can flow to child accounts through relationship inheritance. Resources from different service providersA service provider offers services to consumers. are represented as distinct resource types in kcp kcp An open source horizontally scalable control plane for Kubernetes-like APIs., and access to each is evaluated through the standard SubjectAccessReview mechanism regardless of the provider origin.

Layered Evaluation

Kubernetes RBAC serves as the first gate, enforcing structural access at the API level. When RBAC can make a definitive decision (granting or denying access based on resource-type permissions), the request is resolved immediately. When RBAC has no opinion, typically for fine-grained access decisions that depend on relationships rather than resource types, the request is forwarded to OpenFGA through the authorization webhook for relationship-based evaluation.

OpenFGA is integrated through kcp kcp An open source horizontally scalable control plane for Kubernetes-like APIs.'s standard authorization webhook mechanism. This means that OpenFGA is not a hardwired component: any authorizer conforming to the Kubernetes authorization webhook interface can be configured as an alternative or additional authorization backend, preserving the platform's commitment to pluggability and decoupling.

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.

Integration with the Account Model

The security architecture integrates deeply with 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 kcp An open source horizontally scalable control plane for Kubernetes-like APIs.'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 providersA service provider offers services to consumers. expose new capabilitiesA concrete incarnation of a service that has been created and configured for a specific application or service. 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 consumersAn organization or individual that orders, utilizes, and manages the lifecycle of a service. engage with service providersA service provider offers services to consumers. 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 marketplaceA place where service providers offer various services, and consumers can discover these services., 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.

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 kcp An open source horizontally scalable control plane for Kubernetes-like APIs.'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.

---

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

2. Keycloak ↩︎

3. Kubernetes RBAC Documentation ↩︎

4. OpenFGA ↩︎

5. Zanzibar: Google's Consistent, Global Authorization System ↩︎