An exposed endpoint does not automatically mean a cluster is compromised. The actual risk depends on network reachability, authentication requirements, authorisation controls, admission policies, and the permissions available to the requesting identity.
This article explains how exposed Kubernetes API servers can be abused, how SOC analysts investigate suspicious API activity, which audit events provide useful evidence, and how organisations can detect and prevent unauthorised cluster access.
A cloud security team identifies a Kubernetes API endpoint that is reachable from an unexpected public IP address. The endpoint belongs to a production cluster and responds to connection attempts from outside the organisation's normal network.
Further investigation reveals that the cluster has several service accounts with broad permissions. Kubernetes audit records also show an unfamiliar identity attempting to list resources and create a workload.
The security team must establish whether the endpoint was simply reachable, whether authentication was bypassed or successfully completed, and whether the identity had enough permissions to perform sensitive operations.
The investigation needs to answer five questions:
Was the API server intended to be publicly reachable?
Did the requesting party authenticate successfully?
Which Kubernetes resources could the identity access?
Were workloads, service accounts, secrets, or RBAC permissions modified?
Is there evidence of container execution, data access, or movement beyond the cluster?
These questions highlight an important distinction: network exposure creates an opportunity for access, but authentication, authorisation, and cluster configuration determine what a requester can actually do.
The Kubernetes API server is the control-plane component that exposes the Kubernetes API. It receives requests to create, read, update, and delete cluster resources and coordinates access through authentication, authorisation, and admission controls.
Common interactions include:
Listing pods, services, deployments, and namespaces.
Reading ConfigMaps and, when authorised, Secrets.
Creating or modifying workloads.
Updating service accounts and RBAC bindings.
Executing commands inside containers when permitted.
Modifying cluster configuration through supported API operations.
The API server is not the same as a container application endpoint. It is a management interface for the cluster itself.
Kubernetes supports several authentication mechanisms, depending on the cluster configuration and distribution. These may include client certificates, bearer tokens, and integrations with external identity providers.
After authentication, authorisation determines whether the identity may perform the requested action. RBAC is a common authorisation mechanism, using Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings.
An internet-reachable API server may still be protected by strong authentication and tightly scoped RBAC. Conversely, a privately reachable API server can remain vulnerable if an attacker gains access to the internal network or compromises a privileged identity.
A public endpoint increases the number of systems that can attempt to interact with the API server.
Potential risks include:
Automated discovery and reconnaissance.
Repeated authentication attempts.
Exploitation attempts against vulnerable cluster components.
Use of leaked credentials from untrusted networks.
Increased pressure on authentication and monitoring systems.
Public exposure alone does not establish a vulnerability. Some environments intentionally provide public API access while restricting it through source IP allowlists, strong authentication, and appropriate authorisation controls.
If anonymous access is enabled or authentication is misconfigured, unauthenticated requests may receive access to certain API endpoints.
The resulting impact depends on the permissions assigned to the anonymous identity and the cluster's configuration. A denied request to a protected resource does not prove that other resources are accessible.
Investigators should validate the effective permissions of unauthenticated identities rather than assuming that an exposed API server allows unrestricted access.
An authenticated identity may be able to perform actions far beyond its intended responsibilities because of an overly broad role or binding.
High-risk permissions can include the ability to:
Read Secrets across namespaces.
Create or modify pods and other workloads.
Create or modify service accounts.
Create RoleBindings or ClusterRoleBindings.
Access running containers through the exec subresource.
Modify admission-related or other sensitive cluster resources.
The impact depends on the exact resources, verbs, API groups, and namespaces covered by the role.
Applications running inside Kubernetes may use service account identities to interact with the API server.
If a token is exposed through a compromised pod, insecure logging, an improperly configured workload, or another access path, an attacker may be able to use it within its effective permissions.
A service account token does not automatically provide cluster-administrator access. Investigators must determine the associated identity and its effective authorisation.
The ability to create or modify workloads can be particularly dangerous when combined with other permissions.
For example, a principal that can create pods may be able to request access to resources available to the workload, depending on admission controls, namespace restrictions, and pod security settings.
Risk can increase if the workload can use a powerful service account, mount sensitive resources, access host resources, or communicate with privileged internal services.
A pod-creation permission should therefore be evaluated alongside service account permissions, admission policies, workload restrictions, and network controls.
The following attack paths describe potential abuse patterns from a defensive investigation perspective. Each requires the relevant configuration and permissions; none is guaranteed merely because an API endpoint is reachable.
An attacker discovers a reachable API server and sends requests to determine which endpoints and resources are accessible.
Potential objectives include identifying namespaces, workloads, services, and exposed metadata.
Detection opportunities:
Repeated API requests from unfamiliar source IPs.
Attempts to list resources across multiple namespaces.
Unusual access to API discovery endpoints.
Bursts of denied requests followed by successful resource queries.
Resource enumeration may also be normal behaviour for controllers, monitoring tools, and deployment systems. Detection should account for the identity, request pattern, and expected workload.
If an identity has permission to read Secrets, it may access sensitive configuration or credentials stored in Kubernetes.
Depending on the application, a Secret may contain database credentials, API keys, certificates, or other authentication material.
Detection opportunities:
Unexpected get, list, or watch requests for Secrets.
Access to Secrets across unrelated namespaces.
A new identity reading sensitive resources shortly after authentication.
Secret access followed by unusual activity in a connected application or cloud service.
Kubernetes Secret data is not automatically encrypted at rest in every configuration. Encryption-at-rest settings and access controls should be assessed separately. Even when encryption at rest is enabled, authorised API access can still expose the decrypted data.
A principal with sufficient permissions may create or modify a workload in order to run an application, access available resources, or establish unauthorised execution within a cluster.
The risk depends on the workload's configuration and the permissions of the identity that creates it.
Detection opportunities:
New pods or deployments outside approved namespaces.
Workloads using unexpected service accounts.
Images from unfamiliar registries.
Privileged container settings or unusual host mounts.
Changes made outside recognised deployment pipelines.
A new workload is not necessarily malicious. Correlate the request with deployment records, image provenance, namespace ownership, and the initiating identity.
An identity with excessive permissions may be able to create or modify role bindings or roles to obtain additional access.
Kubernetes includes specific protections around certain privilege-escalation operations. The ability to modify RBAC resources does not mean every such change will succeed.
Detection opportunities:
New ClusterRoleBindings granting broad access.
RoleBindings to unexpected service accounts.
Roles containing sensitive verbs such as bind, escalate, or impersonate.
Changes that grant access to Secrets or workload execution.
RBAC modifications by identities that do not normally manage permissions.
Investigators should compare the binding and role definitions before and after the event and determine the actual permissions granted.
If an identity has permission to use the pod exec subresource, it may be able to execute commands inside a running container.
Depending on the container's environment, this may expose application data, configuration, or credentials accessible to that workload.
Detection opportunities:
Unusual requests to the pods/exec subresource.
Interactive execution by identities that normally deploy workloads but do not administer them.
Execution against sensitive production pods.
Subsequent access to secrets, databases, or internal services.
API audit records may establish that an exec request occurred, but they may not contain a complete record of commands executed inside the container. Correlate with container runtime, EDR, application, and network telemetry where available.
Identify the cluster, API endpoint, cloud account or subscription, environment, and expected network configuration.
Determine whether the endpoint is reachable from the public internet, restricted to approved IP ranges, accessible only through a private network, or exposed through an intermediary service.
Review the cluster's configuration and cloud network controls rather than relying only on a single connectivity test.
Review authentication and API audit records to determine whether requests were associated with:
A human user.
A Kubernetes service account.
An external identity provider.
A cluster component or controller.
An anonymous identity, if supported and enabled.
Capture the username, groups, user agent, source IP, requested resource, namespace, verb, response code, and timestamp where available.
A user-agent string is useful context but should not be treated as definitive proof of identity.
Kubernetes audit logs can record API requests and their outcomes, depending on the configured audit policy and logging backend.
Investigate events involving:
Secret access.
Pod creation and modification.
Role and RoleBinding changes.
ClusterRole and ClusterRoleBinding changes.
Service account modifications.
Pod exec, attach, or port-forward operations.
Namespace and workload changes.
Review both successful and denied requests. Repeated denied requests may indicate reconnaissance or failed attempts to obtain access, while successful requests establish that the API accepted the operation under the applicable controls.
Audit policies that record only metadata may not preserve request or response bodies. Investigators should understand the policy in effect during the incident and avoid assuming that full object contents are available.
Identify the requesting identity's roles and bindings at the time of the incident.
Review:
Namespaced Roles and RoleBindings.
ClusterRoles and ClusterRoleBindings.
Service account assignments to workloads.
Permissions to read Secrets.
Permissions to create workloads.
Permissions to modify RBAC.
Permissions to execute commands in containers.
Where possible, compare current configuration with version-controlled manifests, infrastructure-as-code, or known-good configuration snapshots.
Current permissions may differ from those in effect during the incident, so preserve historical configuration evidence when available.
If the investigation identifies suspicious workload creation or modification, examine the relevant pod, deployment, and ReplicaSet metadata.
Collect:
Namespace and workload name.
Image reference and image digest, where available.
Service account name.
Creation and modification timestamps.
Container security context.
Volume and host-path mounts.
Relevant admission decisions.
Container runtime and application logs.
Deployment pipeline records.
Determine whether the workload was expected, whether it used sensitive credentials, and whether it accessed resources outside its intended scope.
Review evidence of Secret access, application database connections, unusual DNS requests, outbound network traffic, and access to connected cloud services.
Potential evidence sources include:
Kubernetes audit logs.
Container runtime and application logs.
Cloud audit records.
Network flow logs.
DNS and proxy logs.
Cloud provider security findings.
Data loss prevention alerts, where available.
A suspicious API request does not prove that data was successfully exfiltrated. Establish whether the relevant data was accessed, whether a transfer occurred, and whether the destination was unauthorised.
If unauthorised access is confirmed or ongoing, coordinate containment with the Kubernetes platform owner and incident response team.
Potential actions include:
Restricting API server network access.
Revoking or rotating exposed credentials.
Removing unauthorised RBAC bindings.
Disabling or restricting compromised service accounts.
Isolating suspicious workloads.
Preserving audit records and relevant container evidence.
Reviewing cloud credentials available to affected workloads.
Containment should be based on the evidence and operational impact. Avoid deleting a suspicious pod or namespace before preserving the evidence needed to investigate it, unless immediate action is necessary to prevent ongoing harm.
Kubernetes audit logs are commonly structured as JSON events. The exact schema and available fields depend on the Kubernetes version, audit policy, and logging backend.
An illustrative event may contain fields similar to the following:
{ "kind": "Event", "apiVersion": "audit.k8s.io/v1", "level": "Metadata", "verb": "create", "user": { "username": "system:serviceaccount:default:app-service" }, "sourceIPs": [ "10.0.2.15" ], "objectRef": { "resource": "pods", "namespace": "production", "name": "unexpected-workload" }, "responseStatus": { "code": 201 } }This is a fictional example for illustrating the structure of an audit record. It does not represent a real incident.
The record would indicate that the API server recorded a successful pod creation request by the specified service account in the production namespace. It would not, by itself, establish malicious intent or prove that the pod performed harmful actions.
Was the service account expected to create pods?
Was the source IP associated with an approved workload or deployment system?
Was the pod created by a recognised controller or deployment pipeline?
Which image and service account did the pod use?
Did the pod access Secrets or other sensitive resources?
Did the workload initiate unexpected network connections?
These questions connect the API event to the wider cluster activity.
Monitor API requests from unfamiliar source networks, especially when the cluster is intended to be privately accessible.
Enrich the alert with network configuration, identity, user agent, request rate, and authentication outcome.
Alert on unexpected access to Secrets, especially from service accounts or users that do not normally interact with sensitive configuration.
Improve precision by tracking namespace ownership, resource sensitivity, identity history, and whether the access aligns with expected controller activity.
Monitor creation or modification of Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings.
Prioritise changes that grant broad access, introduce unexpected subjects, or permit sensitive operations such as Secret access and workload execution.
Detect workloads created outside approved deployment pipelines or in namespaces where the initiating identity does not normally deploy resources.
Consider image provenance, privileged security contexts, service account selection, host mounts, and unexpected network behaviour.
Monitor pods/exec, pods/attach, and related operations where supported by the audit configuration.
Correlate these events with identity context, target workload sensitivity, source address, and subsequent activity.
A Kubernetes cluster often operates within a wider cloud environment. Correlate Kubernetes events with cloud audit logs to identify potential use of cloud credentials available to a compromised workload.
This may help establish whether suspicious cluster activity was followed by access to object storage, secrets, databases, or cloud management APIs.
The following techniques may be relevant when supported by evidence. Confirm the current descriptions and sub-techniques in the MITRE ATT&CK knowledge base before assigning a final classification.
TechniqueATT&CK IDWhen it may applyExploit Public-Facing ApplicationT1190Evidence shows exploitation of a vulnerable exposed serviceValid AccountsT1078An existing identity or credential is used for unauthorised accessAccount ManipulationT1098Account settings or access mechanisms are modified to expand access or maintain persistenceContainer Administration CommandT1609Evidence supports abuse of container administration interfaces to execute commandsContainer and Resource DiscoveryT1613The actor enumerates containers or related resourcesEscape to HostT1611Evidence supports an escape from a container to its hostAn exposed API server does not automatically imply exploitation of a public-facing application. Similarly, creating a pod does not prove container escape. Select mappings according to the actions demonstrated by the investigation.
Reference: https://attack.mitre.org/
Restrict API server network access. Prefer private endpoints where appropriate. If public access is required, use narrowly scoped network allowlists and review them regularly.
Enforce strong authentication. Use the cluster's supported identity integrations and secure credential lifecycle management. Avoid relying on weak or long-lived credentials.
Apply least-privilege RBAC. Grant identities only the required resources and verbs. Review access to Secrets, workload creation, RBAC management, and container execution.
Secure service accounts. Avoid unnecessary token mounting, restrict service account permissions, and use short-lived projected tokens where supported and appropriate.
Apply admission controls. Use supported admission policies to restrict dangerous workload configurations, including privileged containers, unsafe host mounts, and unauthorised image sources.
Protect the control plane. Keep Kubernetes and managed cluster components supported and updated. Review provider-specific control-plane security settings.
Enable appropriate audit logging. Capture the API operations needed for security investigations and send the records to a protected central destination.
Secure workloads. Apply pod security standards, resource restrictions, network policies, image verification, and appropriate runtime protection.
Monitor configuration drift. Compare live cluster configuration against approved manifests and infrastructure-as-code. Alert on unexpected network exposure, RBAC changes, and sensitive workload modifications.
Test detection coverage. Validate that suspicious API requests, Secret access, RBAC changes, and workload execution generate the expected alerts without disrupting legitimate controllers and deployment pipelines.
Exposed Kubernetes API servers can provide attackers with an entry point for reconnaissance, resource access, workload manipulation, or privilege escalation when additional configuration weaknesses are present.
The severity of an incident depends on more than public reachability. Authentication, RBAC, service account permissions, admission controls, network restrictions, and workload configuration determine the actions an identity can perform.
For SOC analysts, effective investigation means establishing who made each request, whether it succeeded, which permissions applied, and what happened afterward. Kubernetes audit logs should be correlated with workload telemetry, cloud audit records, and network evidence to determine the actual impact.
Organisations can reduce risk through restricted API access, least-privilege RBAC, secure service accounts, admission controls, protected audit logging, and continuous monitoring of cluster configuration.
The objective is not simply to hide the Kubernetes API server from the internet. It is to ensure that every permitted request is appropriately authenticated, authorised, monitored, and constrained.
Kubernetes — Auditing
Kubernetes — RBAC Authorisation
Kubernetes — Controlling Access to the API
Kubernetes — Secrets
MITRE ATT&CK
Continue reading
Cloud Attacks
[{"type":"text","text":" Cloud credential theft occurs when attackers obtain or misuse authentication material that enables access to cloud platforms, applications, or services. Th...
Cloud Attacks
[{"type":"text","text":" Microsoft Entra ID applications and service principals can access organisational resources through delegated permissions, application permissions, and dire...
Cloud Attacks
[{"type":"text","text":" AWS CloudTrail records API activity across an AWS environment, helping security teams investigate identity misuse, unauthorised configuration changes, priv...
3 entries, most recent posts.
Cybersecurity researchers have uncovered an AI-assisted cybercrime operation attributed to CyberXero, a financially motivated initial access broker th...
Senior Hosting Security Engineer
The convergence of Operational Technology (OT), the Internet of Things (IoT), and traditional enterprise IT networks is transforming how organisations...
