Hardeneks Series
- [This post] A Guide to the EKS Cluster Security Assessment Tool
- [Next post] Assessing the Security of an EKS Cluster Built with Terraform
Introduction
When operating Amazon EKS (Elastic Kubernetes Service), it is important to check that security settings are configured correctly. Manually checking each of AWS's EKS Best Practices, however, is tedious and time-consuming.
Hardeneks is a tool officially provided by AWS for this purpose. It is a Python-based CLI tool that automatically checks how well an EKS cluster follows AWS best practices.
This series walks through everything from the basics of Hardeneks to applying it to an actual EKS cluster.
What Is Hardeneks?
Hardeneks is an open-source tool provided by AWS Samples that analyzes EKS cluster security across multiple areas. It checks the following areas.
Security
- IAM: Anonymous access control, service account management, and wildcard permission restrictions
- Multi-tenancy: Namespace quota management
- Detective controls: Checks whether logging is enabled
- Network security: Checks VPC Flow Logs and network policies
- Encryption: EBS and EFS encryption settings
- Infrastructure security: Private subnet deployment and Inspector enablement
- Pod security: PSA (Pod Security Admission) settings
- Image security: Use of immutable tags in ECR
Reliability
- Applications: Metrics Server, VPA, and HPA settings
- High availability: Replica deployment across multiple nodes
- Resource management: Container resource limit settings
Installation and Basic Usage
1. Installation
The simplest approach is to install it with pip.
# 가상환경 생성 (권장)
python3 -m venv hardeneks-env
source hardeneks-env/bin/activate
# hardeneks 설치
pip install hardeneks
2. Basic Usage
# 기본 실행 (현재 kubectl 컨텍스트 사용)
hardeneks
# 특정 리전과 클러스터 지정
hardeneks --region us-east-1 --cluster my-eks-cluster
# 특정 네임스페이스만 검사
hardeneks --namespace production
# 결과를 다양한 형식으로 내보내기
hardeneks --export-html report.html
hardeneks --export-json report.json
hardeneks --export-csv report.csv
3. Configure Required Permissions
Running Hardeneks requires permissions in both AWS and Kubernetes.
AWS IAM Permissions
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListClusters",
"eks:DescribeCluster",
"ecr:DescribeRepositories",
"inspector2:BatchGetAccountStatus",
"ec2:DescribeFlowLogs",
"ec2:DescribeInstances"
],
"Resource": "*"
}
]
}
Kubernetes ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: hardeneks-runner
rules:
- apiGroups: [""]
resources: ["namespaces", "resourcequotas", "persistentvolumes", "pods", "services", "nodes"]
verbs: ["list"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]
verbs: ["list"]
- apiGroups: ["networking.k8s.io"]
resources: ["networkpolicies"]
verbs: ["list"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["list"]
- apiGroups: ["apps"]
resources: ["deployments", "daemonsets", "statefulsets"]
verbs: ["list", "get"]
- apiGroups: ["autoscaling"]
resources: ["horizontalpodautoscalers"]
verbs: ["list"]
Customization: Using a Configuration File
Hardeneks supports customization through a configuration file. By default, it runs all checks, but you can run only specific checks or exclude certain namespaces to suit your environment.
Example Configuration File
# hardeneks-config.yaml
---
# 검사에서 제외할 네임스페이스
ignore-namespaces:
- kube-node-lease
- kube-public
- kube-system
- kube-apiserver
- karpenter
- kubecost
- external-dns
- argocd
- aws-for-fluent-bit
- amazon-cloudwatch
- vpa
# 실행할 검사 규칙 정의
rules:
# 클러스터 전체 검사
cluster_wide:
security:
iam:
- disable_anonymous_access_for_cluster_roles
- check_endpoint_public_access
- check_aws_node_daemonset_service_account
- restrict_wildcard_for_cluster_roles
network_security:
- check_vpc_flow_logs
- check_awspca_exists
- check_default_deny_policy_exists
encryption_secrets:
- use_encryption_with_ebs
- use_encryption_with_efs
reliability:
applications:
- check_metrics_server_is_running
- check_vertical_pod_autoscaler_exists
# 네임스페이스 기반 검사
namespace_based:
security:
iam:
- disable_service_account_token_mounts
- disable_run_as_root_user
- use_dedicated_service_accounts_for_each_deployment
pod_security:
- disallow_container_socket_mount
- disallow_host_path_or_make_it_read_only
- set_requests_limits_for_containers
- disallow_privilege_escalation
- check_read_only_root_file_system
runtime_security:
- disallow_linux_capabilities
reliability:
applications:
- check_horizontal_pod_autoscaling_exists
- schedule_replicas_across_nodes
- run_multiple_replicas
Using the Configuration File
# 커스텀 설정 파일로 실행
hardeneks --config hardeneks-config.yaml
# 설정 파일과 함께 결과 내보내기
hardeneks --config hardeneks-config.yaml --export-html custom-report.html
Key Checks in Detail
1. IAM Checks
- Anonymous access control: Block anonymous user access through ClusterRole and Role resources
- Service account management: Use a dedicated service account for each deployment
- Wildcard permission restrictions: Minimize the use of
*permissions
2. Network Security
- VPC Flow Logs: Enable network traffic logging
- Network policies: Implement default-deny policies
- Load balancer encryption: Use TLS on AWS load balancers
3. Pod Security
- Prevent privilege escalation: Configure
allowPrivilegeEscalation: false - Disallow root users: Run containers as non-root users
- Read-only file system: Set the root file system to read-only
4. Resource Management
- Resource limits: Set CPU and memory requests/limits
- HPA settings: Configure automatic scaling
- Multiple replicas: Eliminate single points of failure
Practical Usage Scenarios
Scenario 1: Production Environment Assessment
# 프로덕션 클러스터 전체 검사
hardeneks --region us-east-1 --cluster production-cluster --export-html prod-security-report.html
# 결과를 Security Hub로 전송
hardeneks --region us-east-1 --cluster production-cluster --export-security-hub
Scenario 2: Focused Assessment of a Specific Namespace
# 특정 애플리케이션 네임스페이스만 검사
hardeneks --namespace my-app --export-json app-security-report.json
Scenario 3: CI/CD Pipeline Integration
# JSON 형식으로 결과 출력하여 파이프라인에서 처리
hardeneks --config ci-config.yaml --export-json pipeline-report.json
# 실패한 검사가 있으면 빌드 실패 처리
if [ $(jq '.failed_checks | length' pipeline-report.json) -gt 0 ]; then
echo "Security checks failed!"
exit 1
fi
Interpreting Results and Making Improvements
Based on the Hardeneks results, improvement work can be prioritized as follows.
1. High-Priority Fixes
- Fix containers running as root
- Address excessive permissions on service accounts
- Fix Pods with no resource limits
2. Medium-Priority Fixes
- Implement network policies
- Enable logging
- Improve encryption settings
3. Long-Term Improvements
- Introduce monitoring tools
- Build an automated security scanning pipeline
- Establish a regular security review process
Closing Notes
Hardeneks lets you assess EKS cluster security item by item. I recommend running it regularly to maintain security standards and integrating it into your CI/CD pipeline for continuous security validation.
Customization through a configuration file also lets you adjust checks to match your organization's security policies.
Coming Next in the Series
In the next post, I will apply Hardeneks to an EKS cluster built with Terraform.
- Terraform EKS cluster configuration analysis: An actual cluster including Karpenter, Istio, and a monitoring stack
- Running Hardeneks and analyzing results: Actual assessment results and identified security issues
- Resolving security issues: Step-by-step security improvements based on the assessment
- Writing a custom configuration file: Optimizing the configuration for the actual environment
References
- Hardeneks GitHub Repository
- Official AWS blog - HardenEKS: Validating Best Practices For Amazon EKS Clusters Programmatically