AWS and Cloudanix team co-authored this blog: Real-Time Threat and Anomaly Detection for Workloads on AWS

Cloudanix

AWS Kubernetes (EKS) Audit

Security groups associated with EKS clusters should allow inbound traffic only on TCP port 443 (HTTPS). This prevents any malicious activities such as brute-force attacks and also meets compliance requirements.

EKS Cluster Should Allow Inbound Traffic only from Port 443(HTTPS)

Security groups associated with EKS clusters should allow inbound traffic only on TCP port 443 (HTTPS). This prevents any malicious activities such as brute-force attacks and also meets compliance requirements.

EKS Clusters Should Have Logging Enabled

EKS clusters should have their control plane logs enabled and publish their API, audit, controller manager, scheduler or authenticator logs to AWS CloudWatch.

EKS Clusters Should Use The Latest Stable Version of Kubernetes

Amazon Elastic Kubernetes Service (EKS) clusters should be using the latest stable version of Kubernetes container-orchestration system, in order to follow AWS best practices, receive the latest Kubernetes features, design updates and bug fixes, and benefit from better security and performance.

Endpoints Should Not Be Publicly Accessible

Your Amazon EKS cluster API server endpoints should not be publicly accessible from the Internet in order to avoid exposing private data and minimizing security risks. The level of access to your Kubernetes API server endpoints depends on your EKS application use cases. It is recommended that the API server endpoints should be accessible only from within your AWS VPC.

EKS Clusters Should Have High Availability

EKS clusters should have a minimum of 3 nodes spread across 3 Availability Zones. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.

ECR Repositories Should Be Private

ECR repository policies should not enable global or public access to images. ECR repository policies should limit access to images to known IAM entities and AWS accounts and avoid the use of account-level wildcards.

ECR Repository Tag Should Be Immutable

Ensures ECR repository image tags cannot be overwritten. ECR repositories should be configured to prevent overwriting of image tags to avoid potentially-malicious images from being deployed to live environments.

ECR Image Repositories Should Have A Lifecycle Policy Attached

A Lifecycle policy should be defined for each Amazon ECR image repository in order to automatically remove untagged and old container images. A lifecycle policy is a set of one or more management rules, where each rule defines an action for Amazon ECR.

Image Vulnerability Scanning Should Be Enabled For Amazon ECR

Image Vulnerability scanning should be enabled for Amazon ECR container images after being pushed to a repository. Amazon ECR image scanning helps in identifying software vulnerabilities in your container images. Amazon ECR uses the Common Vulnerabilities and Exposures (CVEs) database from the open-source Clair project and provides a list of scan findings.

cta-image

Secure Every Layer of Your Cloud Stack with Cloudanix

Unify your security workflows with Cloudanix — one dashboard for misconfigurations, drift detection, CI/CD, and identity protection.

Get Started

CLOUDANIX

Insights from Cloudanix

Explore guides, checklists, and blogs that simplify cloud security and help you secure your infrastructure.