Evaluation¶

This document summarizes the findings from evaluating kcp in Platform-Mesh, including advantages, disadvantages, and open questions.

Advantages¶

Finding	Description
Plain-Vanilla kcp	Relatively standard kcp deployment without heavy customization, making upgrades and maintenance easier.
Current kcp Version	Using kcp version v0.30.0, benefiting from latest features and security patches.
kcp-operator Managed	Deployment is managed by kcp-operator via RootShard and FrontProxy CRs. No self-maintained logic in custom controllers or Helm charts required for core kcp functionality.

Finding	Description
Self-Signed CA Certificate	The rootShard uses a self-signed kcp-ca certificate, which may complicate trust chain management and certificate rotation.
Single-Shard Implementation	Currently deployed as a single shard, limiting horizontal scalability and high availability. Multi-shard is on the roadmap for Q1 2026.
RootShard Not Externally Accessible	The RootShard is currently not accessible from outside the cluster. This is required for host-cluster external controllers (e.g., api-syncagent).
Extensive PermissionClaims	The PermissionClaims on the `core.platform-mesh.io` APIExport are very broad, including full access to all Secrets and LogicalClusters.

Finding	Description
kcp Authorizers Not Used	Several kcp-specific authorizers are not utilized: Global Authorizer (RBAC with ClusterRoles/ClusterRoleBindings in system:admin workspace), RequiredGroupAuthorizer, WorkspaceContentAuthorizer (needs verification), and MaximalPermissionPolicyAuthorizer.
GroupClaims Not Evaluated	No use or evaluation of GroupClaims since ReBAC is used for role-based access control instead.
Fixed Workspace Structure	The workspace hierarchy is pre-defined and fixed (root, platform-mesh-system, orgs, providers).

Question	Context
Auditing	How is auditing configured and implemented for kcp API operations? What audit events are captured and where are they stored?
Account Nesting Restrictions	Can account nesting (WorkspaceType "account" within "account") be restricted or limited? What are the implications for the workspace hierarchy?

The current kcp implementation provides a solid foundation:

Operator-managed lifecycle reduces operational burden
Standard kcp patterns ensure compatibility with upstream documentation and community support
Current version provides access to latest features like WorkspaceAuthentication

Consider addressing these aspects:

Short-Term

Document auditing strategy - Define what kcp API operations should be audited and implement audit logging
Review PermissionClaims - Evaluate if the broad permissions on core.platform-mesh.io APIExport can be scoped down
Verify WorkspaceContentAuthorizer - Check how this authorizer is satisfied

Medium-Term

Enable external RootShard access - Configure external accessibility for host-cluster controllers like api-syncagent
Implement account nesting limits - Define and enforce restrictions on workspace nesting depth

Long-Term

Multi-shard deployment - Implement multi-shard architecture as planned for Q1 2026
CA integration - Replace self-signed certificates with proper PKI integration
GroupClaims evaluation - Consider if GroupClaims could complement or simplify the ReBAC integration

Risk	Impact	Mitigation
Single-shard failure	Complete API unavailability	Plan multi-shard for Q1 2026, implement monitoring
Broad PermissionClaims	Potential privilege escalation	Audit and scope down permissions where possible
Self-signed certificates	Trust chain issues	Document rotation process, plan CA integration
External controller limitation	Cannot deploy controllers outside of the host-cluster	Enable external RootShard access