zop-system Controller
What does zop.dev create for 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.
| Field | Value |
|---|---|
| Cloud | cross-provider |
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
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.