HardenEKS: The Easy Way to keep your AWS EKS clusters secure and compliant

Guide to automating Amazon EKS best practices compliance

🚀 Introduction

is an open source Python CLI that helps you programmatically validate if your EKS clusters follow best practices defined in the

📣 Introducing HardenEKS 📣

HardenEKS is a potent Python-based Command Line Interface (CLI), capable of systematically assessing whether . This comprehensive guide covers six fundamental pillars of best practices for Amazon EKS clusters:

• Security


• Reliability


• Autoscaling


• Networking


• Scalability


• Windows Containers

HardenEKS, a technical marvel in its own right, primarily focuses on these rules derived from the EBPG that can be executed automatically. With a robust set of over 40 carefully designed automated rules already available and more on the way, HardenEKS ensures that your Amazon EKS cluster's adherence to best practices is nothing short of outstanding.

What's impressive is that you don't need to install HardenEKS within the cluster you're validating. Instead, it conducts its validation of all rules from an external standpoint, ensuring a non-invasive and secure assessment of best practices. This accessibility, regardless of your level of experience, makes HardenEKS an indispensable tool for all.

Here's a sneak peek at what you can expect to learn from the article:

1. Getting and installing HardenEKS.


2. Running the validation against your operational Amazon EKS cluster.


3. Creating a comprehensive report with the results.


4. Exploring the structure and details of this generated report.


5. Diving into an illustrative best practice scenario, explaining how fixing the best practice issues brings significant benefits.

🕸️ Prerequisites

As a prerequisite for running the tool, you must already have access to a Kubernetes cluster configured through the kubeconfig file.

To run the tool on an EKS cluster, some minimum permissions must be met, both within AWS (IAM Policy) and within the EKS cluster (RBAC).

Below are the minimum required permissions for the IAM Policy:

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Allow",

            "Action": "eks:ListClusters",

            "Resource": "*"

        },

        {

            "Effect": "Allow",

            "Action": "eks:DescribeCluster",

            "Resource": "*"

        },

        {

            "Effect": "Allow",

            "Action": "ecr:DescribeRepositories",

            "Resource": "*"

        },

        {

            "Effect": "Allow",

            "Action": "inspector2:BatchGetAccountStatus",

            "Resource": "*"

        },

        {

            "Effect": "Allow",

            "Action": "ec2:DescribeFlowLogs",

            "Resource": "*"

        },

        {

            "Effect": "Allow",

            "Action": "ec2:DescribeInstances",

            "Resource": "*"

        }

    ]

}

For more details on configuring IAM policies, refer to the

Moreover, it can easily be implemented in your GitOps approach by adding it to the pipeline.

You can run HardenEKS with just a few commands:

python3 -m venv /tmp/.venv

source /tmp/.venv/bin/activate

pip install hardeneks

hardeneks

The previous command generates an HTML file that highlights the rules that have been violated. Below is a snapshot of the report that HardenEKS provides.

HardenEKS systematically checks each section of the EBPG against your cluster. If a rule is found to be violated, HardenEKS not only identifies the specific configuration that caused the violation, but it also provides relevant information about the corresponding EKS Best Practice.

Each result in the report is accompanied by a link that takes you to detailed information about the best practices related to that particular violation. These results can be used to help you assess and address any issues in your cluster that need attention.

For example, if the report shows that the "Pod Security Policy" rule has been violated, the link will take you to the documentation for the

At the end of each check that the tool performs, it provides a link to the best practices guide.

🛠️ Using HardenEKS for Cluster Configuration Validation and Drift Detection

HardenEKS isn't just a one-time validation tool; it's a dynamic solution that can continually monitor your cluster's configuration. Here's how it works:

✅ Baseline Configuration

Before and after making significant changes to your cluster, HardenEKS captures a snapshot of your cluster's configuration status. This baseline serves as a reference point.

✅ Continuous Monitoring

Once changes are implemented, you can create a new baseline to reflect the updated configuration. This process can be automated and scheduled at regular intervals. It ensures that your cluster remains aligned with best practices automatically.

✅ Detecting Configuration Drift

Comparing these baselines allows you to detect drift—any unintended variations between configurations. Identifying drift is crucial for maintaining the integrity of your Amazon EKS clusters and ensuring that unexpected changes do not compromise their stability.

HardenEKS facilitates this ongoing validation process and supports JSON output, which is highly beneficial. Here's an example of how to export data as JSON and use it for automated validation:

hardeneks --export-json hardeneks_report.json

HardenEKS facilitates this ongoing validation process and supports JSON output, which is highly beneficial. Here's an example of how to export data as JSON and use it for automated validation:

# write StorageClass.yaml with encryption parameter false

cat > StorageClass.yaml <<EOF

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

  name: ebs-sc

provisioner: ebs.csi.aws.com

parameters:

  csi.storage.k8s.io/fstype: xfs

  type: io1

  iopsPerGB: "50"

  encrypted: "false"

EOF



kubectl apply -f StorageClass.yaml

hardeneks --export-json report.json

kubectl delete -f StorageClass.yaml



# write StorageClass.yaml with encryption parameter true

cat > StorageClass.yaml <<EOF

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

  name: ebs-sc

provisioner: ebs.csi.aws.com

parameters:

  csi.storage.k8s.io/fstype: xfs

  type: io1

  iopsPerGB: "50"

  encrypted: "true"

EOF



kubectl apply -f StorageClass.yaml

hardeneks --export-json report2.json



# Shows the difference in the reports before and after the StorageClass change was made

cat report.json | jq --raw-output  '.cluster_wide.security.encryption_secrets."EBS Storage Classes should have encryption parameter.".status'

false

cat report2.json | jq --raw-output  '.cluster_wide.security.encryption_secrets."EBS Storage Classes should have encryption parameter.".status'

true

❇️ Advanced configuration customizablerRules

There is the possibility to inform the . We aim to incorporate as many EBPG rules as possible into HardenEKS, ensuring that it remains a robust tool for best practices validation.

🤝 Contributions welcome

If you're interested in contributing to HardenEKS, we invite you to review our outlining the planned features for upcoming versions. We encourage users to actively participate by creating GitHub issues, thus influencing the direction and priorities of HardenEKS's development journey.

🔚 Conclusion

The idea of ​​this post was to demonstrate the use of the hardeneks tool to carry out a check of good practices in the use of kubernetes.

Also, we've demonstrated how Amazon EKS operators can leverage programmable validation to assess the compliance of their Amazon EKS clusters with the EBPG.

It's always a rewarding endeavor to explore innovative methods for assisting customers in optimizing their Day 2 Operations with Amazon EKS.

We hope that you have found this blog post helpful. If you have any other tips or tricks that you would like to share, please leave a comment below.

♻️ X/Twitter: for more insights on AWS cloud computing and containers.