Security Requirements for Selecting a Managed Kubernetes Service: criteria, vendor questions and tests

A managed Kubernetes service takes the control plane off your hands, but it does not take the security decisions with it, and the defaults you inherit on day one usually decide how exposed your clusters stay. This vendor-neutral guide lists the security requirements to evaluate when choosing a managed Kubernetes offering, from a hyperscaler service to a fully managed "autopilot" style mode or a provider-hosted distribution. It covers the shared responsibility split, control plane access, identity for people and workloads, secrets encryption, node and runtime security, network policy, audit logging, upgrades and the provider's own assurance. It is for platform engineering, cloud security and architecture teams writing an RFP or choosing between providers. Hardening a cluster after purchase is covered in the Kubernetes Security Checklist and our service-specific hardening guides.

Key takeaways

• Get the responsibility split in writing. Know exactly who patches the control plane, etcd, node images and add-ons, and who owns RBAC, network policy and workload configuration.
• A private control plane and federated identity are must-haves. Require a private API endpoint option, SSO for humans and short-lived workload identity federation so pods never hold cloud keys.
• Secrets encryption should use a key outside the cluster. Kubernetes documents KMS v2 envelope encryption as stable from v1.29 and notes that local key providers do not protect against a control plane host compromise.
• You cannot detect what you cannot log. Control plane audit logs must be available, exportable and retained under your control.
• Upgrade cadence is a security property. Upstream maintains only the three most recent minor releases with about a year of patch support each, so the provider's version support and upgrade tooling matter.

Define requirements

• Workload sensitivity: NIST SP 800-190 section 4.3.4 advises separating workloads by sensitivity level, by node pools or by separate clusters. Decide up front whether regulated or internet-facing workloads need their own clusters, and whether you need dedicated or confidential compute nodes.
• Operating model: standard mode (you manage node pools and more settings) or a fully managed mode where the provider runs nodes and enforces a security baseline. The fully managed modes remove node patching work but restrict privileged workloads, host access and some agents.
• Multi-cloud and hybrid: whether you need consistent policy, identity and logging across several providers or on-premises clusters.
• Compliance evidence: CIS publishes benchmarks specific to the major managed services and their fully managed modes, separate from the generic Kubernetes benchmark. Decide which benchmark you will be measured against and ask the provider how its defaults score.
• Residency and sovereignty: where the control plane, etcd backups and logs live, and who at the provider can access them.

Capability areas

Shared responsibility

See the Shared Responsibility Models Guide for writing this split into contracts.

Control plane access

• Private endpoint: an option to make the API server reachable only from private networks, plus authorised IP ranges for any public endpoint. Exposed management interfaces have a long record of abuse; see the Tesla Kubernetes cryptojacking incident.
• Human authentication: SSO through your identity provider with MFA, groups mapped to Kubernetes RBAC, and the ability to disable static client certificates and local accounts. NIST SP 800-190 section 4.3.2 calls for MFA and single sign-on for cluster administration.
• Break-glass control: know how cluster-admin is granted at creation, whether the cluster creator receives permanent admin rights, and whether any credential maps to the system:masters group, which bypasses RBAC and cannot be revoked by removing bindings.
• Anonymous access: anonymous authentication disabled or tightly limited, and the legacy Kubernetes dashboard not deployed by default.

Workload identity and secrets

• Workload identity federation: pods exchange projected service account tokens for short-lived cloud credentials, with per-service-account mapping. Node-level instance credentials shared by every pod should be blockable. See the Kubernetes Workload Identity Checklist.
• Service account tokens: bound, audience-scoped, expiring tokens by default and no legacy long-lived token secrets.
• Secrets encryption at rest: envelope encryption of Secrets in etcd with a customer-managed key in an external KMS, using KMS v2. The Kubernetes documentation states that kms v1 is deprecated since v1.28 and that local providers such as aescbc leave key material on the control plane host. Ask how key rotation and key revocation behave.
• External secret stores: supported drivers for mounting secrets from a secrets manager, so sensitive values need not live in etcd. See the Kubernetes Secrets Security Guide.

Node and runtime security

• Node images: minimal, hardened operating system images with secure boot and integrity monitoring options, automatic security patching and a published response time for critical CVEs.
• Node identity: SP 800-190 section 4.3.5 asks for secure node enrolment, persistent node identity and the ability to isolate a compromised node. Ask how a node proves its identity to the control plane and how quickly a node can be cordoned and replaced.
• Pod Security Admission: the built-in admission controller enforcing the Privileged, Baseline and Restricted Pod Security Standards per namespace, with audit and warn modes for rollout.
• Policy and admission extensibility: support for validating admission policies and third-party policy engines, and for image signature verification at admission. See the Kubernetes Admission Control Guide.
• Sandboxing: optional sandboxed runtimes or isolated node pools for untrusted or multi-tenant workloads.

Network security

• NetworkPolicy enforcement: a CNI that enforces Kubernetes NetworkPolicy (and ideally egress and layer 7 policy), on by default or a single setting away. SP 800-190 section 4.3.3 recommends separating traffic by sensitivity.
• Private nodes and egress control: nodes without public IP addresses, controlled egress through a gateway or firewall, and private access to the registry. See the artefact and container registry selection guide.
• Metadata endpoint protection: blocking pods from the cloud instance metadata service unless explicitly needed.

Logging and detection

• Control plane audit logs: API server audit events available to you, with a documented policy level (metadata, request or full request and response), export to your SIEM and retention you control. See the Kubernetes Audit Log Detection Guide.
• Other control plane logs: authenticator, scheduler and controller manager logs where the provider exposes them.
• Runtime detection hooks: support for runtime security agents (or provider-native threat detection) on nodes, including in fully managed modes where node access is restricted.

Lifecycle and resilience

• Version support: how many minor versions are offered, how long after upstream release, and what happens at end of support. Upstream Kubernetes maintains release branches for the three most recent minor releases, and versions 1.19 and newer get approximately one year of patch support (kubernetes.io, checked November 2026).
• Upgrade tooling: surge or blue-green node upgrades, maintenance windows, deprecated API detection before upgrade and rollback options for node pools.
• Backup and recovery: provider etcd backup scope, and support for workload-level backup to a separate account. See the Kubernetes Backup and Recovery guide.

Evaluation criteria

Small teams with few platform engineers usually reduce risk most by choosing a fully managed mode and accepting its workload restrictions, because node patching and baseline enforcement move to the provider. Larger organisations running privileged agents, GPU or specialised nodes, or multi-tenant platforms tend to need standard mode, and should then weight node lifecycle tooling, policy extensibility and audit depth more heavily.

Questions to ask vendors

• Show us your shared responsibility matrix for the control plane, nodes and each add-on. Who patches what, and within what time for a critical CVE?
• Can the API server be made fully private, and do any of your management operations still need a public endpoint?
• Who receives cluster-admin at creation, can it be removed, and does any credential you issue map to system:masters?
• Can we disable static client certificates, local accounts and anonymous authentication?
• How does workload identity federation work, and can we block pods from using the node's own cloud credentials and the metadata endpoint?
• Do you support KMS v2 encryption of Secrets with our own key, and what happens to the cluster if we disable or rotate that key?
• Which control plane logs can we receive, at what audit policy level, and at what cost?
• How long is each minor version supported, what happens at end of support, and how do you warn us about deprecated APIs?
• Which CIS benchmark applies to your service, and which checks fail on a default cluster?
• How would you notify us if your control plane infrastructure or staff access was compromised?

Red flags

• A public API endpoint that cannot be disabled, or private access only on a premium tier.
• A permanent, non-removable admin binding for the identity that created the cluster.
• Pods able to read node cloud credentials by default with no supported way to block it.
• Secrets encrypted only with provider-held keys and no customer-managed key option for regulated workloads.
• Control plane audit logs unavailable, sampled or retained only briefly by the provider.
• Forced minor upgrades at short notice with no way to test, or versions kept past upstream end of life without a clear patch commitment.

Where identity fits

A managed cluster multiplies non-human identities: service accounts, node identities, add-on controllers, CI deployers and the cloud roles each one federates into. Over-privileged service accounts and mounted tokens turn a single pod compromise into cluster or cloud account compromise, as the Kubeflow cryptomining attacks showed. Score providers on how well you can inventory and scope these identities, and plan to govern them with the Kubernetes NHI Security Guide and the Kubernetes RBAC Guide.

Proof of concept

1. Create a cluster with default settings and run the CIS benchmark for the service against it. Record failing checks; these are the defaults you will inherit.
2. Make the API endpoint private, connect through your network path, and confirm provider operations (upgrades, add-on updates) still work.
3. Connect SSO, map a group to a namespaced role, then remove the creator's admin binding and confirm break-glass access works through your documented process.
4. Enable KMS v2 encryption with your own key, create a Secret, rotate the key and confirm the cluster keeps working; then test what disabling the key does in a sandbox.
5. Deploy a workload using workload identity federation, confirm it gets only its intended cloud permissions, and confirm a second pod cannot reach node credentials or the metadata endpoint.
6. Label a namespace for the Restricted Pod Security Standard in warn and audit mode, review the results, then enforce it.
7. Apply a default-deny NetworkPolicy and confirm traffic is blocked as expected.
8. Stream audit logs to your SIEM, perform a sensitive action (create a ClusterRoleBinding, read a Secret) and confirm it arrives with the identity attached.
9. Run a minor version upgrade on a test cluster with representative workloads and time it, including node pool rollback.

Framework mapping

At control level the requirements also sit in CIS Controls v8.1 Control 4 (Secure Configuration of Enterprise Assets and Software), Control 6 (Access Control Management) and Control 8 (Audit Log Management).

Standards and references

• NIST: SP 800-190 Application Container Security Guide
• Kubernetes: Encrypting Confidential Data at Rest
• Kubernetes: Releases and support policy
• CIS: Kubernetes Benchmarks
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support for managed Kubernetes services, including the service accounts and federated cloud identities your clusters create. Browse vendors in our NHI and AI products directory or contact us.

Related NHI Mgmt Group resources: Kubernetes Security Guide · Kubernetes Security Checklist · Kubernetes Workload Identity Checklist · Security Requirements for Selecting a Cloud Provider · Kubernetes Cluster Compromise Playbook