# 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.

Source: https://zop.dev/integrations/provision/cross-provider/kops-kube-log-agent
Updated: 2026-08-19

---

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

```text
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.