Plaidnox InfoSec
PLX-2025-003  ·  Confidential
Cloud Security Assessment AWS + Kubernetes 3 Critical  ·  4 High

Cloud & Kubernetes
Penetration Test Report

Black-box and authenticated assessment of AWS infrastructure, EKS cluster configuration, IAM permission boundaries, and container runtime security for [REDACTED]. Conducted under authorised engagement agreement ref. ENG-2025-0412.

Report IDPLX-2025-003
Assessment DateFeb 10 – Feb 21, 2025
Report Versionv1.0 — Final
Conducted byPlaidnox InfoSec
01 — Abstract

Executive Summary

Plaidnox InfoSec conducted an authorised cloud and Kubernetes penetration assessment of [REDACTED]' AWS production environment between February 10 and 21, 2025. The scope included the AWS account boundary, three EKS clusters running patient-facing workloads, ECR container registries, and the CI/CD pipeline integration with GitHub Actions.

The assessment identified 11 vulnerabilities across five severity tiers. Three Critical findings represent direct paths to cross-account data exfiltration: an IMDSv1 SSRF chain from a public-facing pod, an overpermissive IAM role attached to worker nodes, and a publicly exposed Kubernetes API server endpoint accepting unauthenticated list operations. Immediate remediation is required before the next production release cycle.

02 — Scope & Methodology

Assessment scope

AWS Account
altera-prod (123456789012)
EKS Clusters
3 clusters (us-east-1)
Environment
Production (read-only scope)
CI/CD Pipeline
github.com/altera-hs
Container Registry
ecr.aws/altera-prod
Assessment Type
Grey-box + CSPM-assisted

Testing followed the OWASP Cloud Security Testing Guide, CIS AWS Foundations Benchmark v2.0, CIS Kubernetes Benchmark v1.8, and MITRE ATT&CK for Containers. All active exploitation was conducted on an isolated staging replica of the production cluster.

03 — Findings Summary

Vulnerability overview

3
Critical
4
High
2
Medium
1
Low
1
Info
IDTitleSeverityCVSSCategory
CLD-001IMDSv1 SSRF via Public-Facing Pod → AWS CredentialsCritical9.6Container Escape
CLD-002Worker Node IAM Role Allows AssumeRole on All AWS ServicesCritical9.1IAM Privilege Escalation
CLD-003Kubernetes API Server Publicly Exposed — Anonymous List AllowedCritical9.0K8s Misconfiguration
CLD-004S3 Bucket with Patient Records Allows Public Read via ACLHigh8.2Storage Exposure
CLD-005ECR Images Running as Root with No Read-Only FilesystemHigh7.4Container Security
CLD-006Secrets Stored in Kubernetes ConfigMaps in PlaintextHigh7.1Secrets Management
CLD-007GitHub Actions Workflow Exposes AWS Credentials via Env VarsHigh6.8CI/CD Security
CLD-008Kubernetes RBAC — ClusterAdmin Binding on Service AccountMedium5.8K8s RBAC
CLD-009CloudTrail Logging Disabled in Two Secondary RegionsMedium4.4Audit & Logging
CLD-010Pod Security Admission Not Enforced on Production NamespaceLow3.2K8s Policy
CLD-011EKS Cluster Version 1.26 — End of Support Since Q1 2024Info0.0Lifecycle
04 — Detailed Findings

Critical findings detail

CLD-001 IMDSv1 SSRF via Public-Facing Pod → AWS Credentials
Critical CVSS 9.6
Description
A URL-fetching feature in the patient portal application (fetch-document endpoint) was exploitable as an SSRF vector. Combined with IMDSv1 still enabled on the underlying EC2 worker nodes, an attacker can retrieve the IAM instance profile credentials for the node's service role via the link-local metadata endpoint http://169.254.169.254/latest/meta-data/iam/security-credentials/.
Reproduction
HTTPSSRF to IMDS credential extraction
GET /api/fetch-document?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/eks-worker-role

# Response — credentials returned to attacker:
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "IQo...",
  "Expiration": "2025-02-11T08:30:00Z"
}
Impact
Impact
Retrieval of the worker node IAM role credentials allows an attacker to authenticate to AWS as the node. Combined with CLD-002 (overpermissive IAM role), this provides a complete path to cross-account privilege escalation and full S3 data exfiltration without requiring direct cluster access.
Recommendation
Remediation
  • Enforce IMDSv2 (session-oriented) on all EC2 instances and EKS node groups by setting HttpTokens: required in the launch template.
  • Implement an allowlist-based SSRF protection on fetch-document — deny all requests to RFC 1918 and 169.254.0.0/16 ranges.
  • Enable AWS VPC endpoint policy to restrict IMDS access to only the Kubernetes control plane service account.
CLD-003 Kubernetes API Server Publicly Exposed — Anonymous List Allowed
Critical CVSS 9.0
Description
The EKS cluster altera-prod-cluster-2 has its API server endpoint configured as public (0.0.0.0/0). Additionally, the RBAC policy includes a ClusterRoleBinding granting list and get permissions on all resources to the system:anonymous principal — unauthenticated requests can enumerate all pods, services, secrets, and configmaps cluster-wide.
Impact
Impact
Any internet user can enumerate the full cluster topology and read sensitive configuration data including ConfigMap values (database connection strings, API keys) stored in the default namespace without any authentication. This directly enables targeted exploitation of CLD-006.
Recommendation
Remediation
  • Restrict EKS API server public endpoint access to specific CIDR ranges (VPN egress IPs only) or disable public access entirely and use a private endpoint with VPN/Direct Connect.
  • Remove all RBAC bindings granting permissions to system:anonymous and system:unauthenticated principals immediately.
  • Run kubectl auth can-i --list --as=system:anonymous after the fix to verify zero permissions remain.
ℹ Findings CLD-004 through CLD-011 are documented in the full technical appendix delivered under the engagement agreement. This report presents the three most critical attack paths identified.
05 — Remediation Roadmap

Prioritised remediation plan

⚠ Priority guidance: CLD-001, CLD-002, CLD-003 must be resolved before the next production deployment. CLD-004 through CLD-007 within 14 days. CLD-008 and below in the next sprint cycle.
IDFindingActionOwner
CLD-001IMDSv1 SSRFEnforce IMDSv2 on all node groups; SSRF allowlist on fetch endpointPlatform Team
CLD-002Overpermissive Node IAM RoleApply least-privilege IAM policy scoped to required S3/ECR operations onlyCloud Infra
CLD-003Public K8s API + Anonymous RBACRestrict endpoint CIDR; remove anonymous RBAC bindingsPlatform Team
CLD-004Public S3 BucketRemove public ACL; enable S3 Block Public Access at account levelCloud Infra
CLD-005Containers Running as RootSet runAsNonRoot: true and readOnlyRootFilesystem: true in pod security contextApp Teams
CLD-006Secrets in ConfigMapsMigrate to Kubernetes Secrets with envelope encryption via AWS KMSPlatform Team
CLD-007CI/CD Credential ExposureReplace long-lived AWS keys with OIDC-based GitHub Actions federationDevOps
Conclusion
Three independent critical attack paths require immediate remediation
The combination of an SSRF-to-IMDS credential chain, an overpermissive node IAM role, and a publicly accessible unauthenticated Kubernetes API server represents a cascading compromise scenario that could result in full data exfiltration of patient health records. Production deployment should be paused until CLD-001, CLD-002, and CLD-003 are resolved and independently verified. Plaidnox recommends a cloud security posture re-baseline within 30 days of remediation completion.
06 — References

References

Confidential — Authorised Distribution Only