rbac-controller-manager

rbac-controller-manager is part of the IPCEI-CIS cloud infrastructure initiative. Within the IPCEI-CIS edge framework it provides the tenant-facing authorization layer of the edge-connect platform.

A kcp-native controller that gives edge-connect its own RBAC API surface (rbac.edge-connect.eu/v1alpha1) and materialises it onto kcp's native RBAC primitives.

What it does

• ClusterRoleBinding → KCP ClusterRoleBinding. Reconciles cluster-scoped ClusterRoleBinding CRs across every workspace bound to the clusterrolebindings APIExport and materialises each one as a native KCP ClusterRoleBinding. Subject names are written in plain form by authors; the controller transparently prepends the oidc: prefix so KCP RBAC sees the identities produced by the workspace authentication configuration.

The ClusterRoles referenced by spec.role (org: owner/read; sub-workspace: workspace-owner/workspace-contributor/workspace-reader) are precreated externally and are not managed by this controller.

Layout

Path	Responsibility
api/v1alpha1	ClusterRoleBinding API types + scheme
cmd/rbac-controller	manager entrypoint (apiexport provider + reconciler)
internal/controller/clusterrolebinding	ClusterRoleBinding → KCP ClusterRoleBinding reconciler
internal/subject	oidc: subject prefixing (pure)
examples	sample ClusterRoleBinding and APIBinding manifests
config/crd, config/kcp	generated CRD and kcp APIResourceSchema
deploy/charts/rbac-controller	workload Deployment + host RBAC
deploy/charts/rbac-controller-kcp	APIResourceSchema, APIExport, consumer RBAC

Development

make all      # generate deepcopy + CRD + kcp schemas
make test     # unit tests (regenerates code first)
make build    # build ./cmd/rbac-controller
make helm-lint
make helm-test # requires the helm-unittest plugin

The controller authenticates to the kcp front-proxy with the kubeconfig at $KCP_KUBECONFIG (mounted by the chart). --endpointslice (default clusterrolebindings) must match the deployed APIExport name.

The runtime chart accepts canonical kcp.connection.kubeconfigSecret or kcp.connection.inlineKubeconfig sources, with released kcp.kubeconfig.existingSecret/value retained as deprecated fallbacks. Source precedence is canonical external, canonical inline, legacy external, then legacy inline. The selected key is mapped to the fixed /etc/kcp/kubeconfig/KCP_KUBECONFIG path. Projected KCP tokens are disabled by default; when enabled they require an audience and expiration of at least 600 seconds and are exposed through the configured tokenFile mount. The kubeconfig used for projected-token authentication must contain this user stanza, where the path must equal <projectedServiceAccountToken.mountPath>/<filename>:

user:
  tokenFile: /var/run/secrets/kcp/token

The runtime chart retains the historical release-derived ServiceAccount default (serviceAccount.name: "", falling back to the chart fullname). Deployments using projected identity should explicitly pin serviceAccount.name, commonly to rbac-controller in edge-connect-system; changing the ServiceAccount name or namespace requires matching RBAC subjects. The KCP chart defaults to the legacy User subject rbac-controller and does not synthesize ServiceAccount subjects. Callers must supply projected or dual subjects explicitly through rbac.subjects. serviceAccount.automountToken defaults to true only to preserve released behavior. Projected-only deployments should set it to false, because this controller does not use ambient management-cluster credentials.

Notes / limitations

• Single replica only: leader election is not yet wired up, so replicaCount > 1 is unsupported.
• The materialised native ClusterRoleBinding carries an owner reference to the cluster-scoped ClusterRoleBinding CR, so Kubernetes garbage collection cleans it up automatically on deletion (no finalizer required).
• The referenced ClusterRoles are precreated externally; a spec.role that names a missing role still produces a binding (operators own role lifecycle).
• Role rules use broad wildcards for the PoC; tightening is deferred.

License

Apache-2.0 — see LICENSE.

Funding and Support

This open source project is part of activities carried out within the Important Project of Common European Interest on Next Generation Cloud Infrastructure and Services (IPCEI-CIS) — FKZ 13IPC005, an EU initiative to build a sovereign, interoperable and energy-efficient cloud-to-edge infrastructure in Europe.

The work in this repository has been supported and co-funded by Deutsche Telekom in the context of IPCEI-CIS, where Deutsche Telekom contributes its expertise in secure, sustainable connectivity and cloud-edge platform orchestration for a European cloud-edge continuum.

Where applicable, further national or European public funding instruments associated with IPCEI-CIS may also have contributed to the development of this software.