Scope and Objectives of Kubernetes Penetration Testing
A Kubernetes penetration test requires clear definition of testing scope before work begins. Written authorization from the infrastructure owner must be obtained and all components included in the assessment area documented: API server, kubelet, container runtime, etcd datastore, network policies, and role-based access control (RBAC).
Testing objectives include identifying misconfigurations, verifying authentication and authorization mechanisms, assessing workload isolation, and uncovering privilege escalation paths. Each stage must be documented for subsequent configuration corrections and improved overall security posture.
- Define testing boundaries and obtain written authorization
- Document all cluster components within scope
- Establish success criteria for each assessment phase
Testing Authentication and Authorization Mechanisms
Kubernetes authentication can be implemented through X.509 certificates, Bearer tokens, proxy authentication, or other methods. Testers must verify proper certificate chain configuration, token expiration requirements, and rotation policies. Special attention should be paid to default credentials and weak passwords in service accounts.
RBAC is the primary access control mechanism in Kubernetes. Verify role bindings (RoleBinding and ClusterRoleBinding), ensure permissions are granted only to necessary subjects, and confirm excessive permissions are not assigned. Check whether roles contain permissions for sensitive actions such as creating privileged pods or accessing nodes.
- Verify certificate configuration and rotation practices
- Assess strength and validity periods of Bearer tokens
- Confirm RBAC enforcement follows principle of least privilege
Assessing API Server Security
The Kubernetes API server is a critical component requiring protection against unauthorized access. Verify TLS encryption is used for all connections, required security plugins (such as PodSecurityPolicy or Pod Security Admission) are enabled, and audit logging is properly configured. Ensure the API server is inaccessible from unmanaged networks.
Test sensitive API endpoints that may expose configuration information, secrets, or allow cluster state modification. Check for authentication bypass possibilities through misconfigured authorization rules permitting anonymous access or request forwarding vulnerabilities.
- Verify TLS presence and configuration on API server
- Assess pod security plugins and network access policies
- Confirm API server events are fully audited
Testing Workload and Container Isolation
Verify workloads use restricted security contexts, such as prohibition of privileged containers, disabling privilege escalation (allowPrivilegeEscalation: false), and read-only filesystems. Evaluate network policy usage to restrict traffic between pods and assess potential paths for lateral movement within the cluster.
Examine secret management and ensure sensitive data is not embedded in plain-text environment variables; dedicated storage systems should be used (including external ones like HashiCorp Vault). Assess resource controls (CPU, memory) and confirm pods cannot exhaust node resources, which could cause denial of service for other workloads.
- Verify security contexts and container privilege restrictions
- Assess network policies and pod-to-pod traffic isolation
- Confirm secrets are stored securely and not exposed in configurations
Evaluating Storage and etcd Security
Etcd is the component storing all cluster state, including configurations and secrets. Verify encryption at rest is implemented, TLS is used for inter-component communication, and etcd access is restricted. Ensure etcd backups are protected and stored securely with access limited to authorized administrators.
Evaluate persistent volume and persistent volume claim management. Verify storage classes are properly configured, storage-level encryption is deployed, and volume access is restricted through RBAC. Confirm pod deletion triggers secure data removal and data does not persist in the system.
- Verify encryption at rest is configured for etcd
- Confirm etcd access is restricted and requires authentication
- Assess storage security and data lifecycle management
Analyzing Network Policies and Segmentation
Kubernetes network policies control traffic between pods. Verify default policies exist that block all ingress traffic and require explicit permission. Ensure policies cover all critical components and contain no exceptions that could be exploited for unauthorized access.
Evaluate network segmentation at the node level and verify network plugins (CNI) support security policies. Confirm service namespaces (such as kube-system) are isolated from user workloads and access to critical services is restricted from lower-privilege pods.
- Confirm network policies require explicit ingress traffic authorization
- Verify policy coverage of all critical components
- Assess isolation of service namespaces
Documenting Findings and Recommendations
After testing completion, prepare a detailed report containing all identified vulnerabilities, their severity, exploitation paths, and potential impact on infrastructure. Each finding must be classified by risk level and accompanied by specific remediation recommendations.
Recommendations must be practical and consider cluster usage context. Prioritize critical issues such as misconfigured RBAC, missing data encryption, or pod security context vulnerabilities. Establish a retesting process after remediation implementation to confirm effectiveness.
- Provide comprehensive report with vulnerability classification
- Offer practical remediation recommendations
- Plan retesting after remediation implementation