How can security teams detect container CLI and API use?

What container CLI and API activity actually tells you

Container CLI and API use is most useful as a signal of control-plane interaction, not just administration. The event stream tells you which principal acted, which endpoint was touched, and whether the action looked like routine automation or an interactive operator session. That distinction matters because the same commands can be benign in a deployment pipeline and suspicious from a workstation or unexpected identity.

What to look for is not only the command itself, but the surrounding context: source host, source IP, user agent, session timing, and whether the action lines up with the normal duties of that identity. When those details show up alongside image pulls, exec into running workloads, role changes, or namespace-wide configuration updates, you have a much stronger detection case than command text alone.

Container environments are especially noisy, so the practical goal is to establish what “normal” looks like for each admin path. Approved automation should have a known identity, known source, and stable command pattern. Interactive use should be rarer, more variable, and easier to attribute to a person or operator workstation. For deeper context on hardening the environment where these signals are generated, see the Container Security Guide.

How to separate legitimate automation from suspicious operator activity

The most reliable detections come from baselining approved automation first. If a pipeline, bot, or controller normally talks to the cluster, its commands should come from a predictable source, use a stable service identity, and stay within a narrow set of verbs. Anything outside that envelope, especially ad hoc exec sessions or manual remediation from nonstandard endpoints, deserves review.

Security teams should also separate human-driven administration from API-driven administration. API use is not inherently malicious, but it becomes high-risk when it is issued by identities that do not normally manage containers, when it arrives from unfamiliar network locations, or when it triggers actions that alter running workloads. The API Security Guide is a useful companion when the question is whether the control plane is being used in ways that the application or orchestration layer did not intend.

Where the activity is clearly container-related, the strongest pattern is a mismatch between privilege and behaviour. A read-only build user that suddenly launches an exec session, a deployment identity that starts enumerating secrets, or a monitoring account that begins changing images all indicate either misuse or a compromised credential path. Reviewing those mismatches is usually more valuable than chasing a single command in isolation.

Which telemetry sources matter most for investigation

Cluster audit logs are the foundation, but they are not enough by themselves. Pair them with management-plane logs, endpoint telemetry from admin workstations, registry logs, and identity logs so you can reconstruct who acted, from where, and through which path. Without those layers, it is easy to miss the difference between a script, a human terminal session, and a compromised token being replayed through the API.

Investigation quality improves when teams can correlate command history with workload change events. A suspicious CLI action is more meaningful when it is followed by a new image pull, an unexpected pod restart, or a privilege or policy change in the same namespace. That correlation helps distinguish a harmless administrative check from an action that changed the blast radius of the environment.

For teams managing clusters at scale, Kubernetes Security Guide is the most direct internal reference for auditability, control-plane visibility, and the runtime signals that make these correlations practical. When the event involves container images or registry access, the Container Image Security Guide helps connect CLI activity to supply-chain and image-trust questions that often show up during investigations.

Risk and Threat Considerations

Container CLI and API access becomes risky when control-plane credentials are too broadly usable or when automation and human admin paths are indistinguishable. In that situation, an attacker who steals a token, API key, or kubeconfig can blend into ordinary operations and use legitimate management interfaces to reach running workloads, images, or cluster settings.

Failure mechanism: Weak separation between interactive administration and approved automation lets malicious use hide inside routine management traffic, especially when logging does not preserve source, identity, and action context together.

Impact: Attackers can exec into containers, change workloads, pull modified images, or alter permissions without needing an obvious exploit chain, which makes containment slower and increases the chance of lateral movement or persistence.

Practitioner Guidance

What to verify: Make sure audit logs actually record the principal, source, verb, object, and outcome for cluster and API actions. If those fields are incomplete, you do not have a reliable basis for separating approved automation from suspicious use.

Decision rule: If the activity came from an identity that should not normally administer containers, treat it as an investigation priority even when the command itself looks routine. Behavioural context is the deciding factor, not whether the API call is syntactically valid.

What to prioritise: Start with identities that have the broadest blast radius, then move to exec, image, and workload-change events. Those actions are often the best indicators that the control plane was used in a way that can change the runtime state of the environment.

Practitioner takeaway: The key detection problem is not “did someone run a container command,” but “was that command issued by the right identity, from the right place, for the right reason, with a traceable path from automation to action.”

Related resources from NHI Mgmt Group

• How should security teams govern AI observability tools that use API keys and CLI automation?
• How should security teams detect API abuse when attackers use valid credentials and legitimate endpoints?
• How should security teams use AI to detect API attacks at machine scale?
• How should security teams choose between API keys, Device Flow, and Client Credentials for CLI apps?