Kubernetes Hardening for a SaaS Platform: When a Managed Cluster Still Needs Its Own Baseline

The short answer

A managed Kubernetes service hardens the control plane for you; everything you deploy and configure on top of it is still yours. For a SaaS platform that means the baseline you need covers five areas the provider will not set for you: who holds cluster access, how nodes are configured, what pods are allowed to do, which workloads can talk to each other, and where secrets and logs go. Measure against the benchmark written for your specific service, pinned to a version, rather than a generic checklist.

Who this is for

This is for the platform lead, head of infrastructure or CTO at a SaaS company running production on EKS, GKE or AKS, usually with customer data in the cluster and a customer questionnaire or SOC 2 or ISO 27001 audit asking how it is secured. It assumes you already know Kubernetes and want to know where the provider's responsibility ends. For the general principle of hardening in a priority order, see cloud and server hardening for an online casino; the logic carries over, the systems differ.

What the provider secures and what you do

The cloud providers publish shared responsibility models for their Kubernetes services, and the split is consistent in outline: the provider runs and secures the managed control plane, and the customer secures what runs above it. Check your provider's current documentation, because the exact boundary shifts between standard and more managed modes (for example autopilot-style offerings).

Layer	Typically the provider	Typically you
Control plane (API server, etcd, scheduler)	Operates, patches, secures	Choose endpoint exposure, enable and retain audit logs
Worker nodes	Supplies an image or managed node option	OS and kubelet settings, patch rollout, node access, upgrades of node groups
Identity and access	Provides integration with cloud IAM	RBAC roles and bindings, service accounts, who is cluster-admin
Workloads	Nothing	Pod security settings, resource limits, image sources
Network	Provides the cluster network	Network policies, ingress and egress rules, namespace isolation
Secrets and data	Offers encryption options	What is stored where, who can read it, rotation
Logging and detection	Offers log sources	Enabling them, retaining them, alerting on them

The mistake that causes most findings is reading "managed" as "secured". The bottom half of that table is where SaaS clusters usually drift from any baseline.

Pick the right benchmark, and pin the version

The CIS Kubernetes Benchmark is written for self-managed clusters. Managed services have their own separate CIS benchmarks, and the managed variants omit control-plane checks you cannot perform. Using the generic benchmark against EKS, GKE or AKS gives you checks that do not apply and misses ones that do.

1. Name the benchmark that matches your service, such as the one for your provider's managed Kubernetes product, not the generic one.
2. Write its exact version into the baseline. Benchmarks are revised, and a scan tool may lag the published version, so record both the benchmark version and the tool version.
3. Know what your scanner can reach. kube-bench's own documentation notes that control-plane nodes of managed services cannot be inspected, though worker nodes can. Control-plane settings you control, such as endpoint access and audit logging, need a cloud configuration review instead.
4. Add the official guidance as a second reference. The Kubernetes project publishes a security checklist, and the NSA and CISA published Kubernetes hardening guidance covering pod security, network separation, authentication and authorisation, and audit logging. Neither replaces the benchmark; they give you a rationale an auditor can read.

The checklist, in priority order

1. Access first. List every subject bound to cluster-admin or equivalent. Remove human use of it, and give each workload its own service account instead of the default. Confirm the API endpoint is restricted rather than open to the internet.
2. Audit logging on, kept, and read. Enable control-plane audit logs, send them somewhere the cluster admin cannot edit, and make sure a person or managed SOC is watching them.
3. Pod security. Enforce a restrictive pod security level for production namespaces: no privileged containers, no host namespaces, non-root users, dropped capabilities. Exceptions go in a register with an owner.
4. Network policy. Default-deny between namespaces, then allow what is needed. In a multi-tenant SaaS platform, this is the control that limits one tenant's compromise.
5. Nodes. Use the provider's maintained node image, restrict node access, and have a rollout process for node upgrades so they do not stay behind.
6. Secrets. Keep secrets out of images and manifests in source control, restrict who can read them in-cluster, and rotate them.
7. Image provenance. Pull from a registry you control, and decide what happens to an image nobody can account for.
8. Re-check on events. New clusters, node pools, namespaces and CI/CD integrations are where configuration drift begins.

Hardening is not the same as a vulnerability scan

A benchmark scan tells you whether settings match a baseline. It does not tell you whether an exposed workload is exploitable. Run both, and keep them separate in the evidence you give a customer or an auditor. The distinction between hardening and patching is covered in hardening vs patching; the same logic holds for clusters.

Limitations

This article is general guidance for managed Kubernetes on the major clouds. It names no benchmark version numbers, prices, durations or AnySec-original figures, because versions change and should be confirmed at the source on the day you write your baseline. It does not cover self-managed clusters in depth, service meshes, or runtime detection tooling, and it is not a substitute for reading your provider's current shared responsibility documentation.

What to do next

Write down the benchmark name and version for each cluster, and list your cluster-admin bindings. If you cannot do either in an afternoon, that is the gap. Request a baseline review for your clusters and tell us the cloud, the number of clusters and whether customer data runs in them. The Security Hardening page describes how an engagement runs and what you receive.

Frequently asked questions

Does a managed Kubernetes service come hardened? Only in part. The provider secures the control plane; nodes, access, workloads, network policy, secrets and logging remain yours.

Which CIS benchmark applies to EKS, GKE or AKS? The one written for your service, not the generic Kubernetes benchmark. Pin its exact version.

Can kube-bench scan a managed cluster? Worker nodes yes; managed control-plane nodes no. Control-plane settings you control need a cloud configuration review.

What should a Kubernetes hardening checklist cover first? Access: cluster-admin bindings, service accounts and API server exposure. Then pod security, network policy, secrets, images and logging.

How often should a SaaS team re-check its Kubernetes baseline? On a calendar and on events such as new clusters, namespaces, integrations and version upgrades.

Sources and review

This article draws on the CIS Benchmarks catalogue (separate managed-service benchmarks), the kube-bench documentation on managed clusters, the Kubernetes project's security checklist, and NSA/CISA Kubernetes hardening guidance, as described in secondary summaries; confirm current versions and wording at the source. It cites no statistics, prices or AnySec-original numbers, case results or SLA figures. Author: AnySec Engineering. Published 2026-10-11; last reviewed 2026-10-11.

---

Related reading

• Cloud and server hardening for an online casino — the priority order for building a baseline.
• Configuration drift for an online casino — the events that undo a baseline and the re-check for each.
• Hardening vs patching for an online casino — which evidence an auditor means by each word.
• Cloud security hardening for a digital bank — a versioned cloud baseline evidenced under DORA.