# zop-system Controller

> zop.dev installs the zop-system controller (zInfraVersion default v0.7.7) on every cluster with a cloud-specific cluster-admin identity: an AWS IAM user or role, an Azure service principal holding Contributor and AKS admin, with GCP and OCI equivalents, plus ClusterRoleBindings, an ingress for the kube-management API, and 1 generated API key.

Source: https://zop.dev/integrations/provision/cross-provider/zop-system-controller
Updated: 2026-08-19

---

The zop-system controller is zop.dev's in-cluster management agent. It gives the platform an authenticated API into each cluster so provisioning, deployment, and management operations can run without hand-distributed kubeconfigs.

## Controller, cluster-admin identity, and ingress

Helm release for the controller, cloud-specific cluster-admin identity (AWS IAM user/role, Azure service principal with Contributor and AKS admin, GCP and OCI equivalents), service account with ClusterRoleBindings, ingress for the kube-management API, and a generated API key.

## zInfraVersion pins the controller release

```text
Deployed per cluster on all four providers; zInfraVersion default v0.7.7.
```

## The control plane's link to each cluster

This is the bridge between the zop.dev control plane and each customer cluster.

## The most privileged object on the cluster

The controller runs with cluster-admin via its ClusterRoleBindings, and its cloud identity is
comparably broad: Contributor plus AKS admin on Azure, an IAM user or role on AWS. Nothing
else the platform installs approaches this scope, because nothing else needs to: this is the
component that provisions, deploys, and manages on the platform's behalf. The honest reading
for a security review is that the controller's identity and API key are crown-jewel
credentials: whoever holds them holds the cluster. Their storage, rotation, and audit
trail deserve the scrutiny usually reserved for root.

## An API instead of kubeconfigs

The alternative this replaces is hand-distributed kubeconfigs: credentials that get copied
into laptops and CI systems, never expire, and never appear in an audit. The controller
inverts that. Each cluster gets one authenticated kube-management API, exposed through the
ingress, with the generated API key as the credential. Access becomes something the platform
mediates and logs rather than something files confer. The ingress is therefore a deliberate
exposure of a very powerful endpoint, and the API key in front of it is what makes that
tolerable.

## Removing it severs management

Provisioning, deployment, and management operations flow through this bridge. Uninstall the
controller, break its identity, or lose its key, and the cluster keeps running while the
platform goes blind to it: workloads unaffected, management severed until reinstalling
restores the path. That failure shape is worth knowing in advance, because it presents as
"everything works except the platform."

## Pinned by zInfraVersion

The controller version is pinned (default v0.7.7), so upgrades are explicit version bumps
rolled like any release rather than silent drift. That is the right posture for the one
component everything else depends on.