Skip to content

Latest commit

 

History

History
94 lines (64 loc) · 6.03 KB

readme.md

File metadata and controls

94 lines (64 loc) · 6.03 KB
Raw

EKS Checks

service-logging

Audit logs should be enabled. Logs provide visibility into operation of the service. From a Security perspective they can be analysed automatically or otherwise to understand anomolous or unexpected use of the service.

service-secrets

Envelope encryption for Kubernetes Secrets with KMS.

service-endpoint

Private Endpoint enabled. Public Endpoint disabled. It is more secure to design a network architecture such that you do not need to access the Kubernetes API via the public internet.

service-endpoint-firewall

If a public EKS endpoint exists then ensure that there is no unrestricted access.

service-security-groups

No unrestricted inbound access to the control-plane. Security Groups can restrict access based on range, port and protocol. This check ensures that at least some restriction is being used. You should implement further restriction.

node-imds

The Instance Metadata Service is where EC2 Instances obtain Role Security Credentials. If it is not needed then it should be disabled. For EKS, some AWS access will always be needed. IMDSv2 uses session-oriented access and so is more secure. A Hop limit of 1 will restrict access to a signle network hop and so workloads running in the container the cluster network will not be able to talk to the service. In combination with node-role this means that in-cluster workloads must use IAM Roles for Service Accounts to access AWS Resources.

node-volumes

Volumes attached to instances can include root volumes and other volumes as well as volumes which are controlled by things like Kubernetes Storage Classes for in-cluster Persistant Volumes. All of these should be encrypted at rest.

node-sgs

No unrestricted inbound access to the nodes. Security Groups can restrict access based on range, port and protocol. This check ensures that at least some restriction is being used. You should implement further restriction.

node-private

Nodes should always reside in a private subnet. Where public access is required then services on nodes can be exposed via LoadBalancers. This check ensures that nodes have no Public IP or Public DNS Name Attached. Also checking associated route tables for IGW routes was considered but deemed not necessary.

node-role

Ensure that nodes only have minimal permissions to access AWS resources. AWS defines the minimal AWS-managed policies for an EKS cluster to function and so this is used to inform this check. This does verify that the nodes only have read-access to ECR but goes further in ensuring nodes follow the core security principle of least privilege.

EKS CIS Benchmark Analysis

See cis-eks.md for an understanding of the exact coverage Sek has.

Areas Not In Scope

You need to draw the line somewhere as complex services depend on and integrate with other components.

All areas identified should still be cotinuously monitored using various tools or custom checks.

  • General IAM best practises.
  • In-Cluster Kubernetes Security Best Practises.
  • Network Audit - VPC Flow Logs.
  • RBAC Implementations.
  • Managed Service Actions Audit - CloudTrail.
  • Detailed K8s audit log analysis.
  • KMS Keys used for any EKS-related encryption should be rotated.
  • Network architecture and VPC Endpoints. https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html
  • CIS Hardening of Nodes / AMI Considerations.
  • CloudWatch Logs Encryptions with CMKs.

Resources

Other Resources