Close exposed Kubernetes and container surfaces

A Kubernetes cluster has several kinds of doors: control-plane endpoints, node services, workload ports, cloud load balancers, registries, storage systems, and administrative interfaces. Security starts by knowing which doors exist, who can reach them, and which identity is required to pass through.

The goal is not to make every component unreachable. It is to expose only the paths the platform needs, authenticate them strongly, and make unexpected exposure easy to detect.

Build an exposure inventory

Create an inventory from the outside in. Record public IP addresses, DNS names, load balancers, Ingress and Gateway routes, NodePort services, control-plane endpoints, firewall rules, and peering paths. Then map the internal surfaces: Services, Pod ports, node daemons, container runtime sockets, storage endpoints, and observability tools.

For each surface, capture:

• its owner and business purpose;
• the expected source networks and identities;
• the authentication and encryption method;
• the data or authority available behind it;
• the signal that proves it is still used;
• the process for removing it.

An unused dashboard with administrator access is not harmless simply because nobody remembers its URL. Unowned exposure should be treated as a defect.

Protect management endpoints

The Kubernetes API should be reachable only from approved administrative and automation paths. Prefer private endpoints where the operating model allows them. If public access is required, restrict source ranges, require strong identity, keep anonymous access disabled, and audit every privileged action.

Apply the same discipline to kubelet APIs, etcd, dashboards, metrics endpoints, deployment systems, and cloud consoles. Do not publish a management interface merely to simplify occasional debugging. Use a controlled access path with short-lived credentials and a clear audit trail.

Kubernetes recommends authorization controls, API auditing, current supported versions, and protection of sensitive endpoints in its security checklist. A firewall is useful, but it does not replace authentication or least-privilege authorization.

Expose workload services deliberately

Start internal workloads with ClusterIP services. Add an Ingress, Gateway, or load balancer only when a consumer outside the cluster needs the application. Avoid broad NodePort exposure unless the design explicitly requires it and node firewalls restrict access.

At the application edge, terminate TLS with managed certificates, authenticate callers, validate request sizes and timeouts, and apply rate limits appropriate to the service. Separate public inference endpoints from administrative, metrics, profiling, and health interfaces. A readiness endpoint may be safe to expose to a load balancer while a debug endpoint is not.

Review cloud security groups and Kubernetes resources together. Deleting an Ingress object does not necessarily prove that every associated cloud rule, address, or DNS record was removed.

Harden node and container boundaries

A Pod that can reach the container runtime socket or mount sensitive host paths can cross the workload boundary. Restrict privileged containers, host namespaces, host networking, host ports, unsafe capabilities, and writable host mounts. Apply the Pod Security Standards with the Baseline or Restricted profile according to workload needs.

Use dedicated node pools for workloads that genuinely require elevated access. Protect those nodes with tighter scheduling, identity, networking, and monitoring controls. An exception should identify the workload, owner, reason, scope, and expiration date.

Treat image provenance as part of the boundary. Pull from approved registries, pin immutable image digests for sensitive workloads, scan images, and prevent unreviewed images from entering protected environments.

Limit east-west reachability

Pod networking is often more open than teams assume. Adopt a networking implementation that enforces Kubernetes NetworkPolicy, then establish default-deny ingress and egress policies for protected namespaces.

Add explicit paths for DNS, artifact storage, registries, telemetry, APIs, and required peer services. Test the denied paths as well as the allowed ones. A policy object that selects no Pods or is unsupported by the installed networking layer does not create isolation.

Network policy limits reachability; application identity and TLS still matter. Use both when a compromised workload must not impersonate a trusted service.

Continuously test the deployed boundary

Configuration review alone misses drift and cloud-side exposure. Combine desired-state checks with safe connectivity tests from representative external, administrative, and in-cluster locations.

Alert on newly public load balancers, permissive firewall rules, unexpected NodePort services, privileged Pods, host namespace use, runtime socket mounts, anonymous access, and changes to admission or network policy. Reconcile findings with an owner rather than accumulating an unactionable scanner backlog.

Polyaxon can keep ML and AI workloads behind consistent platform controls while teams reference approved connections, images, environments, and workload policies. The cluster remains the enforcement boundary, but the platform gives each operation an owner, project, configuration history, and traceable execution context for investigating unexpected exposure.