Kubernetes Security Assessment: Scope, Access Requirements, and Risk Validation

When preparing for a whitebox Kubernetes security assessment, platform engineers, cloud architects, and security teams often pay close attention to the initial access request. That is expected. From a least-privilege perspective, granting an external security team access to both the container orchestration layer and the underlying cloud or physical infrastructure can seem excessive at first.

However, a professional Kubernetes security assessment is not limited to a cluster-only configuration review. Kubernetes does not operate in isolation. Its security depends on the infrastructure that hosts its nodes, routes its networks, manages its data, stores its images, and federates its identities.

A well-configured Kubernetes RBAC policy can still be bypassed if the underlying cloud plane is misconfigured. At the same time, a compromised low-privileged container can become a path to cloud-provider administration if workload identity, IAM, or federation boundaries are weak.

This article explains why a Kubernetes cluster security assessment requires visibility across both the cluster and infrastructure layers, what access is typically needed, and how read-only and administrative access are used for different parts of risk validation.

It is intended for platform engineers, DevOps teams, cloud architects, CISOs, and security teams preparing for a Kubernetes security assessment, Kubernetes penetration test, or container infrastructure review.

The article covers:

• why Kubernetes security assessment requires both cluster and infrastructure visibility;
• when read-only access is enough and when cluster-admin access is needed;
• why EKS, GKE, and AKS assessments require cloud IAM review;
• why staging environments rarely replace production visibility;
• what access is typically required for cloud-managed and on-premises Kubernetes environments.

Cluster Plane vs. Infrastructure Plane

Every modern Kubernetes deployment operates across two connected planes:

The Infrastructure/Cloud Plane: Governed by cloud provider Identity and Access Management (IAM), hypervisors, physical or virtual host operating systems, managed Kubernetes APIs such as EKS, GKE, or AKS, storage systems, and cloud network configurations, including VPCs, security groups, and routing tables.

The Kubernetes Cluster Plane: Governed by the Kube-API server, internal role-based access control (RBAC), service accounts, container runtimes, network plug-ins, and workload-level security boundaries.

Assessing only one of these planes gives an incomplete and potentially misleading view of the security posture. To map realistic attack paths, the assessment must analyze how a vulnerability at the container layer can transition into an infrastructure-layer compromise, and vice versa.

Iterasec’s assessment methodology is built around the trust relationships, handshakes, and architectural configurations that connect these two planes. This is where many high-impact Kubernetes security risks appear: not in a single misconfigured object, but in the way cluster, cloud, identity, network, and workload layers interact.

Why Kubernetes Security Assessment Requires Two Kubernetes Principals

During the assessment, we request the provisioning of two distinct Kubernetes principals: a read-only account and a cluster-admin account.

This dual-principal model is both a safety measure and an operational requirement. It separates passive inspection from active validation, allowing the assessment team to review the cluster safely before performing controlled checks that require administrative permissions.

The Read-Only Principal

The read-only service account or user context is used during the initial phase of the assessment. It allows our team to run automated configuration auditing tools and gather baseline telemetry across all namespaces, RBAC roles, cluster roles, network policies, and workload configurations.

This gives us an accurate structural map of the cluster without introducing operational state changes.

Read-only access is suitable for:

• reviewing cluster-wide configuration;
• mapping namespaces, workloads, and service accounts;
• analyzing RBAC roles, ClusterRoles, RoleBindings, and ClusterRoleBindings;
• checking network policy coverage;
• identifying exposed resources and insecure defaults;
• preparing a safe validation plan for the active testing phase.

The Cluster-Admin Principal

The cluster-admin service account or user context is what moves the assessment from a configuration audit to a practical Kubernetes penetration test.

Without cluster-admin privileges, we can identify suspected vulnerabilities, but we cannot always confirm their real-world impact. This distinction matters: static analysis can show where risk may exist, but controlled validation shows whether the risk is actually exploitable in the assessed environment.

Cluster-admin access is required for several critical validation steps.

Verify Workload Isolation and Pod Security Standards

If we identify a namespace that appears to lack Pod Security Admissions (PSA) or Pod Security Standards (PSS), we must verify whether a malicious actor could exploit this.

We do this by attempting to deploy a temporary, highly privileged container and checking whether the cluster’s admission controllers block it. Without admin access, we cannot confirm whether workload isolation policies are functionally enforced or only present in theory.

Impersonate Service Accounts to Validate Actual Permissions

Kubernetes RBAC can become complex, with thousands of lines of Roles, ClusterRoles, and Bindings. In a Kubernetes RBAC assessment, static analysis alone frequently generates false positives.

To validate real permissions, we use native Kubernetes impersonation features to “test-drive” specific service accounts. This allows us to check whether an account can actually perform actions such as reading secrets or creating pods. It improves accuracy and reduces unnecessary noise for the engineering team.

Confirm Network Policy Enforcement

To verify that database pods, payment processors, or internal services are properly isolated, we run interactive commands within temporary pods to test network boundaries.

This allows us to confirm whether network policies are active, functional, and preventing unauthorized lateral movement.

Validate Container Breakout and Escape Findings

If a workload is allowed to mount sensitive host files or directories into a container, we need to validate whether this creates a practical escape path. This cannot be confirmed through configuration review alone.

Cluster-admin access allows us to execute safe, controlled commands inside temporary containers, inspect what is actually exposed through dangerous host file or folder mounts, and verify whether those mounted paths can be modified. This helps determine whether an attacker who compromises a container could read sensitive host data, overwrite host files, or otherwise affect the underlying node.

We also review node kernel and container runtime versions for known security issues, but this is typically done through version, configuration, and exposure checks rather than running high-risk kernel exploits.

Why Cloud Access Matters in EKS, GKE, and AKS Security Assessments

For an EKS security assessment, GKE security assessment, or AKS security assessment, the Kubernetes cluster cannot be reviewed separately from the cloud resources it depends on. 

The security of containerized workloads depends not only on Kubernetes configuration, but also on the secure configuration of the supporting cloud services.

The Dependency Web of Managed Kubernetes

Kubernetes does not manage its own hardware, network routing, or storage systems. Instead, it translates requests into cloud provider API calls. As a result, even a secure cluster configuration can be undermined by insecure settings in dependent cloud services.

Virtual Machine Nodes

The worker nodes hosting containers are standard cloud virtual machines. If these VMs run outdated machine images, lack boot protections such as Shielded VMs or Secure Boot, or expose administration interfaces like SSH or RDP directly to the public internet, an attacker can bypass Kubernetes security entirely by compromising the host VM directly.

Key Management Services

Kubernetes uses KMS integrations to encrypt secrets at rest. We must verify that the underlying KMS key policies, rotation schedules, and access permissions are configured securely so that unauthorized entities cannot decrypt application secrets.

Cloud Storage and Persistent Volumes

Application data is stored on cloud block storage volumes such as AWS EBS or Azure Managed Disks, as well as object stores such as S3, Google Cloud Storage, or Azure Blob Storage.

If these storage elements are unencrypted, publicly accessible, or lack strict bucket-level access controls, data can be exposed regardless of how secure the cluster’s internal RBAC policies are.

Supporting Platform Services

Managed clusters are frequently integrated with cloud-managed databases, message queues such as Pub/Sub, SQS, or Event Hubs, and secret managers.

If these external services are overly permissive, they can become easy entry points for lateral movement into the cluster.

Identity Federation as a Privilege Escalation Path

Modern cloud-managed Kubernetes clusters implement identity federation — such as AWS IAM Roles for Service Accounts (IRSA), GKE Workload Identity, or AKS Workload Identity — to allow applications running in containers to access cloud resources without static credentials.

This is a security best practice, but it also introduces a serious two-way attack surface that must be reviewed during a Kubernetes cloud security assessment.

Without read-only access to the cloud IAM layer, assessors cannot see or evaluate these trust relationships. This makes it impossible to detect complex, high-severity privilege escalation vectors.

Kubernetes-to-Cloud Escalation

A low-privileged pod within the cluster is mapped to a highly privileged cloud IAM role. If an attacker compromises this pod, they can use the federated token to authenticate as a cloud administrator and gain control over the broader cloud infrastructure.

Cloud-to-Kubernetes Escalation

An attacker compromises a cloud role with permissions to modify virtual machines, networking, or storage. They use this access to inject malicious UserData startup scripts into node configuration, modify cluster network routing to bypass firewalls, or replace container image configurations.

This can allow a full takeover of the cluster from outside Kubernetes itself.

Evaluating these configurations requires read-only visibility into cloud IAM policies, trust relationships, and active configurations.

Why Staging Is Not Enough for Kubernetes Security Testing

A common security strategy is to restrict testing entirely to a dedicated staging or testing environment, keeping production isolated from external assessors.

The intention is understandable. However, staging environments almost never fully reflect the security reality of production. Restricting a Kubernetes security assessment exclusively to staging can introduce critical blind spots and leave high-impact risks undetected.

Why Staging Rarely Shows the Full Risk

The “Quick Patch” Phenomenon

Infrastructure teams frequently apply rapid, manual configuration changes or “hotfixes” directly to production to resolve urgent operational incidents.

Because these changes are often applied outside Infrastructure as Code (IaC) pipelines, they rarely propagate back to staging environments. Over time, production and staging diverge, leaving production-specific vulnerabilities invisible in the test environment.

Missing Operational Integrations

Staging environments are rarely integrated with the full suite of security monitoring, logging, and performance solutions used in production.

Vulnerabilities or configuration flaws within these auxiliary systems may go unnoticed if production is never reviewed.

Lack of Real CI/CD Pipeline Connections

Staging environments are often deployed using static configurations or localized manual pipelines. Production, however, is usually driven by automated CI/CD systems such as GitHub Actions, GitLab CI, or Jenkins.

These automated deployment pipelines require highly integrated, federated cloud permissions, which makes them a major target for attackers.

Case Study: The GitHub Actions Federation Takeover

During a recent assessment, our client provided access to two Google Cloud GKE clusters: the active production cluster and a staging cluster created specifically for the security assessment.

The staging cluster was configured with identical workload manifests and identical internal RBAC settings, seemingly offering a perfect representation of the production environment.

However, the staging cluster was deployed manually, while the production cluster was connected to an automated GitHub Actions CI/CD pipeline utilizing Google Cloud Workload Identity Federation.

Our review of the cloud IAM federation settings revealed a critical, high-severity misconfiguration: the GCP Workload Identity Pool trusted the client’s GitHub organization but lacked specific repository-level restrictions.

As a result, any developer or automation workflow in any repository within the company’s GitHub organization, including unprivileged internal tools or test repositories, could request a GCP token.

This token mapped directly to a highly privileged GCP service account that possessed full ClusterAdmin permissions over the production GKE cluster.

Because the staging environment was never integrated with this automated pipeline, this high-severity vulnerability — which allowed for a total compromise of production via any developer’s GitHub account — was completely absent in the staging cluster.

The Read-Only Production Compromise

If internal compliance policies strictly prohibit active administrative testing in production, we strongly recommend a balanced compromise: provide full read-only access to production cloud IAM settings, supporting services, and cluster configuration.

This read-only access allows us to:

• identify and document the real conceptual differences between staging and production environments;
• audit production-specific identity federations, CI/CD integrations, and KMS keys;
• discover critical architecture-level vulnerabilities that only exist in production;
• filter out false positives that may exist in staging but are irrelevant in production, saving engineering teams valuable time.

This approach does not replace active validation, but it significantly reduces the risk of missing production-specific attack paths.

On-Premises Kubernetes Assessments

Unlike cloud-managed services, where the underlying infrastructure is abstracted and managed through provider APIs, an on-premises Kubernetes deployment requires a bottom-up systems engineering audit.

There is no cloud provider responsible for host operating systems, hypervisors, or disk encryption. These layers are owned by the organization operating the cluster, which means they must be included in scope.

To perform a reliable and complete security assessment of an on-premises cluster, we require Root/SSH access to both Worker Nodes and Master Nodes.

Worker Nodes: Rationale for Root-Level Access

Auditing Container Runtime Interfaces

Worker nodes run container engine daemons such as containerd or Docker that manage container lifecycles. We must access these hosts directly to verify that the runtime software is up-to-date and free from known container runtime vulnerabilities that could allow an attacker to escape container boundaries.

Evaluating Local Privilege Escalation Paths

If an attacker succeeds in escaping a container, they usually reach the host operating system with root-level privileges. In hardened environments, however, they may still be constrained to a low-privileged user context.

We audit worker nodes to verify that there are no local privilege escalation paths, such as vulnerable Linux kernels, insecure sudo configurations, or misconfigured local services, that would allow them to escalate to root on the physical machine.

Detecting Hardcoded Credentials

We check the node’s local filesystems for insecure configurations. For example, we verify that application logs do not contain hardcoded sensitive keys or passwords that could become accessible to an unintended or rogue container and result in privilege escalation.

Master Nodes: Rationale for Root-Level Access

The master nodes host the core components of the Kubernetes cluster, including the API server, controller manager, scheduler, and ETCD database.

We must access these nodes directly to verify the configuration of these critical components.

Control Plane Hardening and Anonymous Access

We inspect the runtime configurations of the control plane components to ensure that insecure, anonymous access ports are disabled and that all communication is restricted to authenticated, secure channels.

API Server Encryption Configurations

The Kube-API server must be configured to encrypt sensitive resources before writing them to the database.

We log into the master nodes to verify that the Kube-API server process is running with the --encryption-provider-config flag active, pointing to a secure, strong encryption configuration file.

Direct ETCD Interrogation

The ETCD database stores the entire state of the cluster, including all configuration details, service tokens, and secrets. If an unauthorized user gains access to a backup of this database or can read the raw data files, they can compromise the entire cluster.

We log directly into the master nodes to connect to ETCD bypasses, verifying that:

• the ETCD database requires secure, client certificate authentication for all connections;
• the raw database contents are encrypted on disk;
• secrets and configurations cannot be read in plaintext when manually querying the raw database keys.

Registry, Network, and Ingress Security

A Kubernetes security assessment should also include the systems around the cluster, especially when the scope includes Kubernetes container security, registry access, and workload validation. Container registries, ingress paths, private network access, and management endpoints all influence the practical attack surface.

Container Registry Access

Assessors require read access to container image registries such as AWS ECR, GCP Artifact Registry, or Azure ACR.

This access is necessary to:

Scan for Embedded Secrets and Credentials

We check whether developers have accidentally baked static database passwords, API keys, or private SSH keys directly into container images.

Verify Software Vulnerability Posture

We inspect container base images for known software vulnerabilities to ensure applications are built on secure, up-to-date operating system packages.

Audit Registry Access Controls

We verify that only authorized users, automation systems, and service principals possess permissions to push or read images from registries. This helps protect against unauthorized image injection attacks.

Ingress and Network Access Requirements

In many secure architectures, the Kube-API server’s management endpoint is isolated from the public internet.

If the cluster is located inside a private network, our team requires secure access through one of the following methods:

• a secure VPN tunnel routing directly to the private network;
• a managed jump host or bastion node configured inside the network;
• IP whitelisting on the network’s border firewalls for our secure assessment source IPs.

Technical Appendix: Reference Access Blueprint

This appendix provides platform, IAM, and security engineering teams with reference policy templates and role definitions required to configure access for the security assessment.

It is structured by platform and designed for implementation through a cloud management console, CLI, or Infrastructure-as-Code (IaC) pipeline.

The exact configuration should always be adapted to the client’s environment, scope, identity model, and internal access control policies.

Amazon Web Services IAM Configuration

For AWS environments, relying solely on the built-in ReadOnlyAccess (arn:aws:iam::aws:policy/ReadOnlyAccess) is insufficient.

While it allows viewing ECR metadata, standard AWS read-only policies do not permit data plane operations such as retrieving ECR authentication tokens or downloading container image layers.

To perform the full range of checks, including automated cloud configuration audits and static container image analysis, the client must grant the following custom IAM policy to our assessment principal:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ManagedPolicyEquivalent",
      "Effect": "Allow",
      "Action": [
        "arn:aws:iam::aws:policy/ReadOnlyAccess",
        "arn:aws:iam::aws:policy/SecurityAudit"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EcrDataPlaneAccess",
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage"
      ],
      "Resource": "*"
    },
    {
      "Sid": "IterasecAWSConfigReviewSupplement",
      "Effect": "Allow",
      "Action": [
        "ds:ListAuthorizedApplications",
        "ec2:GetEbsEncryptionByDefault",
        "ecr:Describe*",
        "support:Describe*",
        "tag:GetTagKeys",
        "lambda:GetFunction",
        "glue:GetConnections",
        "glue:SearchTables",
        "s3:GetAccountPublicAccessBlock"
      ],
      "Resource": "*"
    }
  ]
}

Google Cloud Platform IAM Configuration

For GKE assessments, the GCP Service Account with JSON credentials and the user console identity provided to our team must have the following roles assigned over the in-scope projects.

Configuration Blueprint

Assign these built-in IAM roles to the assessment principal:

roles/viewer: Allows general read-only visibility across the project’s infrastructure resources, such as virtual machines, network configurations, and basic cluster states.

roles/resourcemanager.folderViewer & roles/resourcemanager.organizationViewer: Allows our team to understand the organization’s resource hierarchy and verify how permissions are inherited from parent folders.

roles/iam.securityReviewer & roles/iam.organizationRoleViewer: Crucial for retrieving and auditing GCP IAM policies, role bindings, and custom roles to identify privilege escalation risks.

roles/artifactregistry.reader: Grants read and pull access over the Google Artifact Registry, enabling the assessment team to download and scan container images for vulnerabilities or hardcoded secrets.

Microsoft Azure RBAC Configuration

For AKS assessments, the Azure principal, either a user account or service principal, provided to our team must be assigned the following built-in Azure RBAC roles at the subscription or target resource group level.

Configuration Blueprint

Assign these built-in Azure roles to the assessment principal:

Reader: Allows read-only access to view all resources and configurations inside the scope.

Security Reader: Grants permission to view security recommendations, compliance postures, and alerts within Microsoft Defender for Cloud and Azure Security Center.

Reader and Data Access: Crucial for inspecting storage account configurations, checking SAS tokens, and viewing encrypted container details.

Azure Kubernetes Service Cluster User Role: Required to download the AKS cluster’s user kubeconfig context.

AcrPull: Grants read-only access to authenticate and download container images from the Azure Container Registry (ACR).

Kubernetes Cluster-Internal RBAC Configuration

To perform a thorough security assessment of the cluster plane, the two Kubernetes principals provided to our team must be configured with specific authorization profiles.

Principal 1: Read-Only Principal

The read-only principal must be assigned a custom global view role to allow comprehensive inspection of cluster-wide configurations, including Secrets, Roles, RoleBindings, and CustomResourceDefinitions (CRDs).

Your team can apply the following YAML manifest to create and bind this custom role:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: assessor-readonly-global-view
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: assessor-readonly-global-view-binding
subjects:
  - kind: User # Change to 'ServiceAccount' if using an in-cluster token
    name: assessor-readonly-user
    namespace: default
roleRef:
  kind: ClusterRole
  name: assessor-readonly-global-view
  apiGroup: rbac.authorization.k8s.io

Principal 2: Cluster-Admin Principal

The administrative principal can be granted full administrative control over the cluster plane using one of two methods: applying an in-cluster ClusterRoleBinding or mapping the principal directly to the native system:masters group.

Option A: ClusterRoleBinding

If the platform supports standard RBAC binding, apply the following YAML manifest to bind the assessor’s admin principal directly to the built-in cluster-admin role:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: assessor-admin-binding
subjects:
  - kind: User # Change to 'ServiceAccount' if using an in-cluster token
    name: assessor-admin-user
    namespace: default
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Option B: Native Group Association via system:masters

Alternatively, the administrative principal can be associated directly with the native Kubernetes system:masters group through the platform’s authentication mechanism, for example, client certificates, OIDC claims, LDAP group mappings, or another identity provider integration.

Members of the system:masters group are granted unrestricted administrative access to the cluster and bypass standard RBAC authorization checks. This approach is functionally equivalent to assigning the cluster-admin role, but is managed at the authentication layer rather than through Kubernetes RBAC objects.

When using this method, ensure that the assessor’s principal is mapped to the system:masters group for the duration of the assessment and that the mapping is removed afterward if persistent administrative access is not required.

Final Thoughts

A Kubernetes security assessment should not be reduced to a checklist of cluster objects. Kubernetes risk usually appears across boundaries: between workloads and nodes, service accounts and cloud roles, registries and CI/CD pipelines, staging and production, cluster RBAC and infrastructure permissions.

That is why proper scope matters. Without visibility into both the Kubernetes cluster plane and the infrastructure or cloud plane, an assessment may confirm that individual settings look secure while missing the attack paths that matter most.

Iterasec helps teams assess Kubernetes, cloud, registry, CI/CD, and workload security as one connected environment rather than isolated layers. Contact us to discuss the right scope for your Kubernetes security assessment.