kops-kube Log Agent
What does zop.dev create for kops-kube Log Agent?
zop.dev installs kops-kube per cluster on all 4 providers: a Helm release bound to a kops_kube_reader cluster role, an ingress, cloud identity (IAM on AWS; identity user, API key, group, and policy on OCI), and a generated API key that authenticates the platform's log and inspection calls.
| Field | Value |
|---|---|
| Cloud | cross-provider |
kops-kube is zop.dev’s in-cluster log and inspection agent. It exposes a read-only view of cluster state and logs to the platform through a scoped API.
Log agent with cloud identity and an API key
Helm release, a kops_kube_reader cluster role, ingress, cloud identity (IAM on AWS; identity user, API key, group, and policy on OCI), and a generated API key.
Deployed per cluster on every provider
Deployed per cluster on all four providers.The kops_kube_reader role bounds access
Access is read-only by design via the kops_kube_reader cluster role.
Read-only enforced by RBAC, not promise
The agent’s access is bounded by the kops_kube_reader cluster role. The read-only scope is
a property of Kubernetes RBAC, verifiable by inspecting the role, not a behavioural claim
about the agent. That distinction is what makes the component auditable: a security review
does not need to trust the binary, only to read the verbs the role grants. It also bounds the
blast radius of the worst case: a compromised log agent can see cluster state, which is bad,
but cannot mutate it, which is the difference between an incident and a catastrophe.
Two credentials arrive with it
Installation creates a cloud identity (IAM on AWS; on OCI, an identity user with API key, group, and policy) and generates an API key for the agent’s own endpoint. Both are standing credentials that belong in the rotation inventory. The generated API key is the one guarding the interesting surface. It stands between the internet-adjacent ingress and your logs, so treat it with the same seriousness as a database password, and remember teardown should retire the cloud identity too, not just the Helm release.
The ingress is the deliberate exposure
The agent ships with an ingress because its purpose is to be reachable: the platform calls in to read logs and inspect state without anyone distributing kubeconfigs. That is a conscious trade. Logs are sensitive (they leak schema, internal hostnames, and the occasional secret someone printed), and the ingress makes them reachable by anyone holding the API key. Network scoping of that hostname, where possible, is cheap defense in depth on top of the key.