Three SecOps directors have told me some version of the same story this year: the platform team had run Kubernetes for years, an auditor finally asked who was monitoring it, and it abruptly became the security operations center (SOC) problem. The SOC had no cluster admin or kubectl access and no say in how the clusters were built.
I've been on the receiving end of that handoff, and the honest answer is that the SOC's Kubernetes job is narrower than the hardening checklists that dominate the search results. Those checklists are written for the person who runs the cluster.
The SOC's primary contribution is monitoring and incident operations, while hardening stays a shared preventive-control responsibility, so the work starts with telemetry, detections, and clear response ownership.
In brief:
- From the SOC seat, Kubernetes security begins with control-plane visibility, runtime telemetry, detection content, and an agreed containment model, not ownership of every cluster-hardening control.
- Self-managed Kubernetes needs an audit policy and backend. Managed services differ: Amazon EKS control-plane logs aren't sent to CloudWatch by default, Google GKE Data Access logs must be enabled, and Azure AKS needs diagnostic settings before logs are collected and routed.
- Kubernetes API audit logs can detect high-value control-plane behaviors such as anonymous requests, service account token creation, pod exec, and role-based access control (RBAC) changes, but runtime telemetry is still needed for in-container and host-boundary activity.
- Put after-hours containment in writing: who can revoke permissions, rotate credentials, scale down a workload, isolate a node, or change RBAC when an alert fires.
Two seats, two different Kubernetes security jobs
In the textbook, Kubernetes security covers protecting clusters and workloads across the container lifecycle, configurations included. From the SOC seat, most of that is somebody else's job: pod security contexts, network policies, admission control, image scanning.
What's left is a narrower question: can my team see the API server, can we detect the attack patterns that show up there, and who has the access to contain an incident when something fires at 2 a.m.? Ownership varies by organization, so treat what follows as a recommended split, not a universal one.
What the cluster admin owns, and what the SOC owns
The platform team typically owns node configuration, runtime classes, cluster upgrades, the GitOps pipeline, and the agents on nodes. In centralized security models, though, a cloud-security or security-engineering team may operate runtime agents and cluster policies.
Application teams own their workloads' behavior and the permissions they request, within guardrails the platform or security teams enforce. The SOC owns detection content, incident response playbooks, and detection tuning. Preventive controls get pushed into the platform layer as Policy as Code, out of the SOC's reactive queue.
Containment tests this division. The on-call security engineer may lead the incident, but actions such as rotating service account tokens, revoking RBAC bindings, and draining nodes usually require platform-level access, so the platform team, cloud security, or an incident commander executes them.
The SOC typically leads triage and threat assessment, and some SOCs also hold scoped access for selected reversible actions. Pretending the split is clean just means the runbook fails the first time it's load-bearing.
What the SOC actually needs to see in Kubernetes
Two telemetry layers cover most of the detection job, and only one is realistically in the SOC's control. The Kubernetes API server audit log is the primary source for control-plane activity, though not a complete picture on its own, so pair it with cloud-provider logs, Kubernetes events, runtime telemetry, and identity logs.
Runtime telemetry covers activity inside containers. The SOC usually consumes both but depends on the platform team to configure them.
Audit logs, API server events, and workload behavior
The API server audit log records who called the Kubernetes API.
Requests to the kube-apiserver are evaluated against an audit policy, and the resulting JSON events can carry fields such as user.username, verb, objectRef.resource, sourceIPs, the response code, and annotations recording whether authorization was allowed or forbidden, subject to the audit level and the provider's implementation.
That's enough to build detections for high-priority control-plane activity such as privilege abuse and pod creation.
Runtime telemetry is the second layer, and it sees activity beyond the audit log's reach. An attacker who has already exec'd into a pod and is working inside the container's process space generates no further API audit entries; they generate syscalls, which a runtime sensor such as Falco, using eBPF-based capture, can observe.
Effective cloud-native detection therefore depends on combining runtime and control-plane data. The catch is that runtime sensors run as agents on nodes, deployed and operated by the platform or security-engineering team.
Where the useful signal lives, and what's off by default
Much of this signal is unavailable until someone explicitly configures it. Self-managed Kubernetes requires an audit policy and backend before API audit events are written.
Managed services differ by provider. On Amazon EKS, control-plane log types are off by default for CloudWatch delivery and must be enabled individually. On Google GKE, Admin Activity logs are always on, while Data Access logs (ADMIN_READ, DATA_READ, DATA_WRITE) stay disabled until enabled.
On Azure AKS, control-plane logs aren't collected or stored until a diagnostic setting routes them somewhere.
Audit data that was never collected can't be retroactively recreated from Kubernetes audit logging, though related evidence may survive in cloud, identity, runtime, or CI/CD logs.
Once the logs flow, ship them by detection question, not at one universal level. Secrets and ConfigMaps belong at Metadata level so request and response bodies never write sensitive contents into the log.
Use Request or RequestResponse selectively for high-value mutations where the object body matters for investigation, such as selected RBAC or workload-security changes, rather than prescribing RequestResponse for everything.
Keep get, list, and watch events selectively rather than dropping them wholesale, since they can reveal reconnaissance or unusual data access by sensitive identities.
Exclude known health checks and expected system noise only after validating the provider policy and your reconstruction needs, because production clusters can generate substantial audit volume, which makes filtering a budget decision as much as a signal one.
Where Kubernetes attacks show up in SOC telemetry
Palo Alto Networks Unit 42 reports, from its own telemetry, a 282% year-over-year increase in Kubernetes-related threat-actor operations including token theft. Read that as vendor-observed activity, not an industry-wide attack rate.
The strongest control-plane signals center on anonymous access, token creation, pod exec, and RBAC changes, while runtime telemetry covers the in-container behavior that follows.
Exposed API server, over-permissioned service accounts, container escape
CrowdStrike documented a Dero cryptojacking operation that targeted publicly accessible Kubernetes APIs configured with anonymous authentication. In audit logs, that class of attack reads as a recognizable pattern: requests from user.username "system:anonymous" enumerating cluster resources, followed by creation of a workload such as a DaemonSet to spread malicious pods.
Service account abuse is nearly as visible. A useful detection hypothesis is to alert on newly created high-privilege bindings, especially ClusterRoleBinding names that resemble system components, since documented RBAC backdoors have used that disguise.
Unit 42, from the same telemetry, observed potential service-account-token-theft activity in 22% of the cloud environments it examined in 2025.
TokenRequest activity is worth monitoring because short-lived service account tokens can be created through the API with no filesystem footprint.
The core audit pattern is a successful create against the serviceaccounts/token subresource; enrich it with the requesting identity, the target service account and namespace, source IP, authorization context, and your normal automation allowlists.
Metadata-level logging shows that a token was requested, but detecting unusually long requested lifetimes needs Request-level logging or higher, because the expirationSeconds parameter is otherwise absent.
Container escape splits across both layers, and the audit log alone doesn't prove it. An API request to the pods/exec subresource is a high-value investigation signal when it targets a sensitive namespace, service account, or privileged workload, but it isn't, by itself, evidence of escape.
Runtime telemetry is what detects suspicious post-exec behavior and possible host-boundary activity; relevant syscalls such as mount, setns, or unshare are examples to pair with container privilege, hostPath, and capabilities context, not standalone rules.
Direct kubelet API access is a separate blind spot. Kubernetes doesn't subject it to admission control or record it in API audit logging, and depending on configuration it can expose pod information, logs, and command execution in containers. Treat it as a verification task, not an assumption.
Aqua Security's Shodan-based scan found roughly 287,000 internet-connected kubelet endpoints but assessed only 27 as externally exploitable, 15 of which returned at least one service account token. So inventory your own exposure, test reachability and authentication, and collect compensating node and runtime telemetry.
Datadog's 2025 cloud report, separately, found managed API servers exposed to the internet on 39% of EKS and 34% of AKS clusters, which is exposure, not compromise.
What the SOC can detect, and what it has to ask the platform team for
The division of labor works when the SOC requests visibility explicitly. Audit telemetry supports detections the SOC can own directly, while logging, runtime sensors, forensics, and containment still require a platform-team agreement.
The division of labor that actually works
When I inherited monitoring for a fleet of EKS clusters, I first found an empty log group. The control plane logs we needed were not turned on, and the platform team had a defensible answer: nobody asked, and CloudWatch ingest isn't free.
From audit telemetry alone, my team could then own anonymous access detection, exec monitoring, RBAC change alerts, token creation rules, and privileged pod creation. Negotiation covered turning logs on and setting retention, the runtime sensor decision, node-level forensics, and containment authority.
Managed platforms may not let the customer control the audit policy, so confirm the thing you want to detect is logged at all before writing the rule.
That negotiation has to produce a written agreement, because the recurring runtime-alert failure mode is a SOC analyst who lacks the platform context to triage the alert at 2 a.m. while the cloud team that has it isn't staffed for response.
Make it a version-controlled operating agreement that names the in-scope clusters, the required control-plane and runtime log sources, retention and SIEM destinations, the excluded noisy event classes, the on-call contacts, and the authorized containment actions with their approval and rollback paths. Hold the platform team, and yourself, to it.
Where this connects to the rest of your cloud detection
Adjacent Kubernetes security programs each have an accountable owner the SOC should respect rather than absorb, and the exact split varies by organization. Their findings and alerts may reach the SOC, but the underlying programs do not automatically belong there. Clear ownership keeps those handoffs from becoming another undifferentiated queue.
CVEs, container runtime, and CNAPP, and who owns each
In one workable model, the security team sets Common Vulnerabilities and Exposures (CVE) standards and SLAs and approves exceptions with the accountable risk owner, the platform team maintains hardened base images and pipeline scanning, and application teams patch.
Runtime detection tooling divides the same way: platform or security-engineering teams run the Falco pipeline, while security owns the policies and response. A cloud-native application protection platform (CNAPP) often sits with the cloud security team while the SOC answers its runtime alerts, though it could belong to platform or product security instead.
Without shared context and clear ownership, the tool can work while the workflow fails.
Each of those is its own program, and I'd run each separately. But if the Kubernetes handoff landed on my desk this quarter, my first artifact would be that one version-controlled operating agreement. My second would be a tabletop: an anonymous API request, a suspicious TokenRequest, a high-privilege RBAC binding, a pods/exec, and a runtime alert.
The goal isn't only to prove the alert fires. It's to prove someone has the context, access, and authority to act after hours. I've written checks for a lot of cloud detection tooling over the years, and those tools only mattered once that agreement existed.
Frequently asked questions about Kubernetes security
What does Kubernetes security mean from the SOC seat?
Kubernetes security covers protecting clusters and workloads across the container lifecycle, but from the SOC seat it narrows to detection and incident coordination.
Preventive controls such as pod security contexts, network policies, and admission control sit mainly with the platform team, while detection, investigation, and response playbooks sit with the SOC, with the API server audit log as the primary control-plane telemetry source.
Containment usually depends on platform-level access for actions such as rotating tokens, revoking RBAC bindings, and draining nodes, so ownership should be an agreed split rather than an assumption.
What should the SOC monitor in Kubernetes?
The highest-signal audit log events are anonymous API access (user.username "system:anonymous"), service account token creation, pod exec and attach, RBAC role and binding changes, privileged pod creation, and secret access. These cover several high-value control-plane behaviors, not every compromise path.
Where the platform team runs a runtime sensor such as Falco, the SOC should also consume in-container process and file events, which catch post-exec activity the audit log can't see.
What is the difference between SOC and platform responsibility for Kubernetes?
The platform team typically owns cluster configuration, upgrades, the GitOps pipeline, node agents, and enforcement, while the SOC owns detection content, alert tuning, and incident response playbooks.
Containment actions like rotating tokens, revoking RBAC bindings, and draining nodes usually require platform access, so the two teams need a written escalation agreement before the first incident. Exact ownership varies by organization.
What Kubernetes logs should go to the SIEM?
Ship API server audit events for security-sensitive activity: RBAC changes, pod exec, attach, and port-forward, service account token creation, authentication events, and anonymous requests.
Log secrets and ConfigMaps at Metadata level only so their contents never land in the security information and event management (SIEM) system, and use Request or RequestResponse selectively where the object body matters for investigation rather than universally.
Filter high-volume health and system get, list, and watch traffic and known CI/CD accounts after confirming what your provider logs, since production clusters generate substantial volume.