Building STIG-compliant AMIs for Amazon EKS

{"value":"As more organizations required to run hardened virtual machines to increase security to meet the internal compliance adopt Kubernetes, there is a need for hardened Amazon Machine Images (AMIs) that work with [Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/).\n\nThere are multiple options to choose from. One solution is to use [ottlerocket](https://github.com/bottlerocket-os/bottlerocket/), a special-purpose OS from AWS designed for running Linux containers. Bottlerocket includes only the essential software required to run containers, thereby effectively reducing the attack surface and ensuring that the underlying software is always secure. Another option is to consider using hardened images from the [AWS Marketplace](https://aws.amazon.com/marketplace).\n\nIn this post, we discuss the different approaches you can take to achieve a hardened AMI that works with Amazon EKS. We demonstrate how to create an [Amazon Elastic Compute Cloud (Amazon EC2) Image Builder](https://aws.amazon.com/image-builder/) pipeline that applies operating system security requirements defined by the Defense Information Systems Agency (DISA) [Security Technical Implementation Guides (STIGs)](https://public.cyber.mil/stigs/) to an [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/) image. You can then add EKS binaries and other related files on the custom image. Finally, the custom image is used to create an EKS cluster.\n\n### **Approach 1: Apply hardening scripts onto an EKS Optimized Amazon Linux AMI**\nIn this approach, you have existing hardening scripts and a pipeline that you can apply on top of the EKS default AMI to build a hardened image. The following diagram depicts this approach.\n\n\n\nFigure 1. OS Hardening scripts on EKS Optimized Amazon Linux AMI\n\nThe Amazon EKS Optimized Amazon Linux AMI is built on top of Amazon Linux 2 and is configured to serve as the base image for Amazon EKS nodes. The AMI is configured to work with Amazon EKS, and it includes Docker, kubelet, and the AWS Identity and [Access Management (IAM)](https://aws.amazon.com/iam/) Authenticator.\n\nIf you have an existing OS hardening script, you can create a pipeline to run these scripts onto the EKS Optimized Amazon Linux AMI to produce a custom AMI to be used with Amazon EKS.\n\nBecause AWS regularly applies the latest security patches and operating system updates as part of the latest AMI release version, the AMI ID for Amazon EKS Optimized AMIs is available by querying the [AWS Systems Manager](https://aws.amazon.com/systems-manager/) Parameter Store API. You can then programmatically run the pipeline to update the custom AMI and update the EKS cluster to use the AMI.\n\n### **Approach 2: Install EKS-related binaries on a hardened image**\nIn the second approach, instead of using the Amazon EKS Optimized AMI, you can use an existing custom “golden” AMI. The AMI is typically hardened to meet STIG or Center for Internet Security (CIS) standards and might include features such as a vulnerability scanning agent and a couple of monitoring agents. STIGs and CIS are the two primary third-party baselines adopted across public and private organizations. Some enterprises might be inclined to use STIGs as the baseline because they address US government requirements. STIGs are the configuration standards submitted by OS or software vendors to DISA for approval.\n\nOnce approved, the configuration standards are used to configure security hardened information systems and software. STIGs contain technical guidance to help secure information systems or software that might otherwise be vulnerable to a malicious attack. DISA develops and maintains STIGs and defines the vulnerability [Severity Category Codes (CAT)](https://dl.dod.cyber.mil/wp-content/uploads/stigs/pdf/U_Microsoft_Office_2016_V1R2_Overview.pdf), which are referred to as CAT I, II, and III. Once you have the hardened base image, you can install EKS-related binaries to create a custom hardened AMI. The following diagram depicts this approach where the EKS-related binaries are layered on top of the existing golden AMI.\n\n\n\nFigure 2. EKS binaries on Enterprise custom AMI\n\nAn [Amazon Linux 2 CIS image from the AWS Marketplace](https://www.cisecurity.org/cis-hardened-images/amazon/) can be used as the base image as well. CIS pre-hardens these virtual machine (VM) images to CIS Benchmark standards, and you can add EKS-related binaries. These images do incur some additional cost on the AWS Marketplace.\n\nIf you do not have an existing baseline AMI for use with Amazon EKS and wish to create one based on STIG, you can follow the steps in this post to see how to build a golden Linux operating system image that follows STIG compliance guidelines using [Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/).\n\n#### **Create AMI with STIG standards using Amazon EC2 Image Builder**\nAmazon EC2 Image Builder provides a step-by-step wizard covering the steps to build a golden image that follows STIG compliance guidelines.\n\n#### **Define the source image**\nThe first step is to create a recipe in Amazon EC2 Image Builder. Give the recipe a name.\n\n\n\nFigure 3. Create recipe\n\nNext define the base OS image to use as the foundation layer of the golden image. You can select an existing image that you own, an image owned by Amazon, or an image shared with you. Under **Source Image**, select **Amazon Linux** as the image operating system.\n\n\n\nFigure 4. Select managed images\n\n\n\nFigure 5. Select image origin\n\nUnder **Components**, choose the **stig-build-linux-high** component. Image Builder provides STIG components that you can leverage to quickly build STIG-compliant images on standalone servers by applying local Group Policies. The STIG components of Image Builder scan for misconfigurations and run a remediation script. Image Builder defines the STIG components as low, medium, and high, which align with DISA CAT I, II, and III respectively.\n\n\n\nFigure 6. Choose build components\n\nOnce done, select **Create Recipe**.\n\nNext, we choose **Create pipeline from this recipe**.\n\n\n\nInput the **Pipeline name**.\n\n\n\nFigure 8. Specify Pipeline Details\n\nOnce done, select **Create Pipeline** and run the pipeline.\n\n\n\nFigure 9. Run pipeline\n\nAfter some time, the output image becomes available.\n\n\n\n#### **Install EKS binaries on top of hardened AMI**\nTo create a custom Amazon Linux AMI for Amazon EKS, you must use the following:\n\n- [HashiCorp Packer](https://packer.io/intro/why.html) (available from the HashiCorp website)\n- A build specification with resources and configuration scripts from the [Amazon EKS AMI repository on AWS GitHub](https://github.com/awslabs/amazon-eks-ami)\n\n\n**Note:** Packer works using an [AWS CloudFormation](https://aws.amazon.com/cloudformation/) stack. The stack runs an m4.large or a1.large [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/pm/ec2/) instance (depending on the target AMI architecture). The instance is provisioned by Packer. After the instance is provisioned with packages and binaries, Packer creates an AMI from the running instance.\n\n[Install Packer](https://www.packer.io/intro/getting-started/install.html) from the HashiCorp website into your preferred system. Packer supports Windows, Mac, or Linux. In this example, we use an EC2 Linux.\n\n```\n$ sudo yum -y install packer\n```\n\n\n\n\n\nTo clone the Amazon EKS AMI repository to your workstation, run the following command:\n\n```\n$ git clone https://github.com/awslabs/amazon-eks-ami && cd amazon-eks-ami\n```\n\n**Note:** Packer is executed through a series of makefile targets with [eks-worker-al2.json](https://github.com/awslabs/amazon-eks-ami/blob/master/eks-worker-al2.json) as the build specification. The build process uses the [amazon-ebs Packer builder](https://packer.io/docs/builders/amazon-ebs.html) (from the HashiCorp website) and launches an instance. The [Packer shell provisioner](https://www.packer.io/docs/provisioners/shell.html) (from the HashiCorp website) runs the ```install-worker.sh``` script on the instance to install software and perform other configuration tasks. Then, Packer creates an AMI from the instance and terminates the instance after the AMI is created.\n\nTo configure a custom source AMI, set the variables ```source_ami_id```, ```source_ami_owners```, ```source_ami_filter_name``` and ```aws_region``` in the Packer configuration file ```eks-worker-al2.json```.\n\nAn example follows:\n\n```\n\"aws_region\": \"ap-southeast-1\",\n\"source_ami_id\": \"ami-0cc93a9132225a429\",\n\"source_ami_owners\": \"<AWS Account ID>\",\n\"source_ami_filter_name\": \"AL2-STIG-High-Recipe*\",\n```\n\nStart the build process by providing the Kubernetes version as the parameter, and run the following command.\n\n```$ make 1.21 ```\n\n\n\nThe new image will be available in the EC2 AMIs.\n\n\n\n#### **Launch EKS cluster with custom AMI**\nYou can now make use of the custom AMI for Amazon EKS. In this example, ```eksctl``` is used to create the EKS cluster.\n\nDownload and extract the latest release of ```eksctl``` with the following command.\n\n```\n$ curl --silent --location \"https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz\" | tar xz -C /tmp\n```\n\nMove the extracted binary to /usr/local/bin.\n\n```\n$ sudo mv /tmp/eksctl /usr/local/bin\n```\n\nTest that your installation was successful with the following command:\n\n```\n$ eksctl version\n```\n\nCreate the ```cluster.yaml``` with the custom AMI ID:\n\n```\napiVersion: eksctl.io/v1alpha5\nkind: ClusterConfig\nmetadata:\n name: managed-cluster\n region: ap-southeast-1\n\nmanagedNodeGroups:\n - name: custom-ng\n ami: ami-0c51983d4f4f751e7\n overrideBootstrapCommand: |\n #!/bin/bash\n /etc/eks/bootstrap.sh managed-cluster\n```\n\nNext, create the cluster with the cluster.yaml as input.\n\n```\n$ eksctl create cluster --config-file=cluster.yaml\n```\n\nThe cluster with the hardened AMIs is now ready for use.\n\n\n\nFrom the EC2 console, we can see that these custom nodes are using the custom AMI ID.\n\n\n\n### **Summary**\nIn this post, we showed how to build a custom STIG compliant hardened AMI that works with Amazon EKS. We used the Amazon EC2 Image Builder to apply STIG components, installed Kubernetes binaries on the custom AMI and created an EKS cluster with the new AMI. This solution is an option for organizations looking to deploy compliant Amazon EKS environments. The resulting images should still be independently audited and scanned by your internal security organization to ensure they meet the latest standards.\n\nIf you are looking to learn more about Amazon EKS best practices, please check out the [EKS Best Practices Guides](https://aws.github.io/aws-eks-best-practices/).\n\n\n\n**Wayne Toh**\n\nWayne Toh is a Specialist Solutions Architect for Graviton at AWS. He focuses on helping customers adopt ARM architecture for large scale container workloads. Prior to joining AWS, Wayne worked for several large software vendors, including IBM and Red Hat. His hobbies include road cycling and trance music.","render":"<p>As more organizations required to run hardened virtual machines to increase security to meet the internal compliance adopt Kubernetes, there is a need for hardened Amazon Machine Images (AMIs) that work with <a href=\"https://aws.amazon.com/eks/\" target=\"_blank\">Amazon Elastic Kubernetes Service (Amazon EKS)</a>.</p>\n<p>There are multiple options to choose from. One solution is to use <a href=\"https://github.com/bottlerocket-os/bottlerocket/\" target=\"_blank\">ottlerocket</a>, a special-purpose OS from AWS designed for running Linux containers. Bottlerocket includes only the essential software required to run containers, thereby effectively reducing the attack surface and ensuring that the underlying software is always secure. Another option is to consider using hardened images from the <a href=\"https://aws.amazon.com/marketplace\" target=\"_blank\">AWS Marketplace</a>.</p>\n<p>In this post, we discuss the different approaches you can take to achieve a hardened AMI that works with Amazon EKS. We demonstrate how to create an <a href=\"https://aws.amazon.com/image-builder/\" target=\"_blank\">Amazon Elastic Compute Cloud (Amazon EC2) Image Builder</a> pipeline that applies operating system security requirements defined by the Defense Information Systems Agency (DISA) <a href=\"https://public.cyber.mil/stigs/\" target=\"_blank\">Security Technical Implementation Guides (STIGs)</a> to an <a href=\"https://aws.amazon.com/amazon-linux-2/\" target=\"_blank\">Amazon Linux 2</a> image. You can then add EKS binaries and other related files on the custom image. Finally, the custom image is used to create an EKS cluster.</p>\n<h3><a id=\"Approach_1_Apply_hardening_scripts_onto_an_EKS_Optimized_Amazon_Linux_AMI_6\"></a><strong>Approach 1: Apply hardening scripts onto an EKS Optimized Amazon Linux AMI</strong></h3>\n<p>In this approach, you have existing hardening scripts and a pipeline that you can apply on top of the EKS default AMI to build a hardened image. The following diagram depicts this approach.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/9fe634fe74564e89bc260037c55ebbb8_image.png\" alt=\"image.png\" /></p>\n<p>Figure 1. OS Hardening scripts on EKS Optimized Amazon Linux AMI</p>\n<p>The Amazon EKS Optimized Amazon Linux AMI is built on top of Amazon Linux 2 and is configured to serve as the base image for Amazon EKS nodes. The AMI is configured to work with Amazon EKS, and it includes Docker, kubelet, and the AWS Identity and <a href=\"https://aws.amazon.com/iam/\" target=\"_blank\">Access Management (IAM)</a> Authenticator.</p>\n<p>If you have an existing OS hardening script, you can create a pipeline to run these scripts onto the EKS Optimized Amazon Linux AMI to produce a custom AMI to be used with Amazon EKS.</p>\n<p>Because AWS regularly applies the latest security patches and operating system updates as part of the latest AMI release version, the AMI ID for Amazon EKS Optimized AMIs is available by querying the <a href=\"https://aws.amazon.com/systems-manager/\" target=\"_blank\">AWS Systems Manager</a> Parameter Store API. You can then programmatically run the pipeline to update the custom AMI and update the EKS cluster to use the AMI.</p>\n<h3><a id=\"Approach_2_Install_EKSrelated_binaries_on_a_hardened_image_19\"></a><strong>Approach 2: Install EKS-related binaries on a hardened image</strong></h3>\n<p>In the second approach, instead of using the Amazon EKS Optimized AMI, you can use an existing custom “golden” AMI. The AMI is typically hardened to meet STIG or Center for Internet Security (CIS) standards and might include features such as a vulnerability scanning agent and a couple of monitoring agents. STIGs and CIS are the two primary third-party baselines adopted across public and private organizations. Some enterprises might be inclined to use STIGs as the baseline because they address US government requirements. STIGs are the configuration standards submitted by OS or software vendors to DISA for approval.</p>\n<p>Once approved, the configuration standards are used to configure security hardened information systems and software. STIGs contain technical guidance to help secure information systems or software that might otherwise be vulnerable to a malicious attack. DISA develops and maintains STIGs and defines the vulnerability <a href=\"https://dl.dod.cyber.mil/wp-content/uploads/stigs/pdf/U_Microsoft_Office_2016_V1R2_Overview.pdf\" target=\"_blank\">Severity Category Codes (CAT)</a>, which are referred to as CAT I, II, and III. Once you have the hardened base image, you can install EKS-related binaries to create a custom hardened AMI. The following diagram depicts this approach where the EKS-related binaries are layered on top of the existing golden AMI.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/9e94dc9df8e947118461deaa61d754a3_image.png\" alt=\"image.png\" /></p>\n<p>Figure 2. EKS binaries on Enterprise custom AMI</p>\n<p>An <a href=\"https://www.cisecurity.org/cis-hardened-images/amazon/\" target=\"_blank\">Amazon Linux 2 CIS image from the AWS Marketplace</a> can be used as the base image as well. CIS pre-hardens these virtual machine (VM) images to CIS Benchmark standards, and you can add EKS-related binaries. These images do incur some additional cost on the AWS Marketplace.</p>\n<p>If you do not have an existing baseline AMI for use with Amazon EKS and wish to create one based on STIG, you can follow the steps in this post to see how to build a golden Linux operating system image that follows STIG compliance guidelines using <a href=\"https://aws.amazon.com/image-builder/\" target=\"_blank\">Amazon EC2 Image Builder</a>.</p>\n<h4><a id=\"Create_AMI_with_STIG_standards_using_Amazon_EC2_Image_Builder_32\"></a><strong>Create AMI with STIG standards using Amazon EC2 Image Builder</strong></h4>\n<p>Amazon EC2 Image Builder provides a step-by-step wizard covering the steps to build a golden image that follows STIG compliance guidelines.</p>\n<h4><a id=\"Define_the_source_image_35\"></a><strong>Define the source image</strong></h4>\n<p>The first step is to create a recipe in Amazon EC2 Image Builder. Give the recipe a name.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/a808d70131664f4c959c8615c18a8b33_image.png\" alt=\"image.png\" /></p>\n<p>Figure 3. Create recipe</p>\n<p>Next define the base OS image to use as the foundation layer of the golden image. You can select an existing image that you own, an image owned by Amazon, or an image shared with you. Under <strong>Source Image</strong>, select <strong>Amazon Linux</strong> as the image operating system.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/aca5dbe3c69847e7a6c51181ad49da60_image.png\" alt=\"image.png\" /></p>\n<p>Figure 4. Select managed images</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/fb121dc11d26423e93190ba67f57c0f4_image.png\" alt=\"image.png\" /></p>\n<p>Figure 5. Select image origin</p>\n<p>Under <strong>Components</strong>, choose the <strong>stig-build-linux-high</strong> component. Image Builder provides STIG components that you can leverage to quickly build STIG-compliant images on standalone servers by applying local Group Policies. The STIG components of Image Builder scan for misconfigurations and run a remediation script. Image Builder defines the STIG components as low, medium, and high, which align with DISA CAT I, II, and III respectively.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/5f18b06233104e16bededa75ae5b0681_image.png\" alt=\"image.png\" /></p>\n<p>Figure 6. Choose build components</p>\n<p>Once done, select <strong>Create Recipe</strong>.</p>\n<p>Next, we choose <strong>Create pipeline from this recipe</strong>.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/4c36ac56fcaf4cf5939b8cdd4e8ce6f5_image.png\" alt=\"image.png\" /></p>\n<p>Input the <strong>Pipeline name</strong>.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/16ad2181da324368b024ac133962a607_image.png\" alt=\"image.png\" /></p>\n<p>Figure 8. Specify Pipeline Details</p>\n<p>Once done, select <strong>Create Pipeline</strong> and run the pipeline.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/d1bc67f61943464ba75754db462e9a1d_image.png\" alt=\"image.png\" /></p>\n<p>Figure 9. Run pipeline</p>\n<p>After some time, the output image becomes available.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/abf8fb1ca4e84092b4e58fbe8c32daf7_image.png\" alt=\"image.png\" /></p>\n<h4><a id=\"Install_EKS_binaries_on_top_of_hardened_AMI_80\"></a><strong>Install EKS binaries on top of hardened AMI</strong></h4>\n<p>To create a custom Amazon Linux AMI for Amazon EKS, you must use the following:</p>\n<ul>\n<li><a href=\"https://packer.io/intro/why.html\" target=\"_blank\">HashiCorp Packer</a> (available from the HashiCorp website)</li>\n<li>A build specification with resources and configuration scripts from the <a href=\"https://github.com/awslabs/amazon-eks-ami\" target=\"_blank\">Amazon EKS AMI repository on AWS GitHub</a></li>\n</ul>\n<p><strong>Note:</strong> Packer works using an <a href=\"https://aws.amazon.com/cloudformation/\" target=\"_blank\">AWS CloudFormation</a> stack. The stack runs an m4.large or a1.large <a href=\"https://aws.amazon.com/pm/ec2/\" target=\"_blank\">Amazon Elastic Compute Cloud (Amazon EC2)</a> instance (depending on the target AMI architecture). The instance is provisioned by Packer. After the instance is provisioned with packages and binaries, Packer creates an AMI from the running instance.</p>\n<p><a href=\"https://www.packer.io/intro/getting-started/install.html\" target=\"_blank\">Install Packer</a> from the HashiCorp website into your preferred system. Packer supports Windows, Mac, or Linux. In this example, we use an EC2 Linux.</p>\n<pre><code class=\"lang-\">$ sudo yum -y install packer\n</code></pre>\n<p><img src=\"https://dev-media.amazoncloud.cn/a3bb386cdc12496198e8eed9847a5f17_image.png\" alt=\"image.png\" /></p>\n<p>To clone the Amazon EKS AMI repository to your workstation, run the following command:</p>\n<pre><code class=\"lang-\">$ git clone https://github.com/awslabs/amazon-eks-ami &amp;&amp; cd amazon-eks-ami\n</code></pre>\n<p><strong>Note:</strong> Packer is executed through a series of makefile targets with <a href=\"https://github.com/awslabs/amazon-eks-ami/blob/master/eks-worker-al2.json\" target=\"_blank\">eks-worker-al2.json</a> as the build specification. The build process uses the <a href=\"https://packer.io/docs/builders/amazon-ebs.html\" target=\"_blank\">amazon-ebs Packer builder</a> (from the HashiCorp website) and launches an instance. The <a href=\"https://www.packer.io/docs/provisioners/shell.html\" target=\"_blank\">Packer shell provisioner</a> (from the HashiCorp website) runs the <code>install-worker.sh</code> script on the instance to install software and perform other configuration tasks. Then, Packer creates an AMI from the instance and terminates the instance after the AMI is created.</p>\n<p>To configure a custom source AMI, set the variables <code>source_ami_id</code>, <code>source_ami_owners</code>, <code>source_ami_filter_name</code> and <code>aws_region</code> in the Packer configuration file <code>eks-worker-al2.json</code>.</p>\n<p>An example follows:</p>\n<pre><code class=\"lang-\">&quot;aws_region&quot;: &quot;ap-southeast-1&quot;,\n&quot;source_ami_id&quot;: &quot;ami-0cc93a9132225a429&quot;,\n&quot;source_ami_owners&quot;: &quot;&lt;AWS Account ID&gt;&quot;,\n&quot;source_ami_filter_name&quot;: &quot;AL2-STIG-High-Recipe*&quot;,\n</code></pre>\n<p>Start the build process by providing the Kubernetes version as the parameter, and run the following command.</p>\n<p><code>$ make 1.21 </code></p>\n<p><img src=\"https://dev-media.amazoncloud.cn/42a5393ccbc446b49516fedec92bbe58_image.png\" alt=\"image.png\" /></p>\n<p>The new image will be available in the EC2 AMIs.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/19ca8c6444a444e699eff5977a110872_image.png\" alt=\"image.png\" /></p>\n<h4><a id=\"Launch_EKS_cluster_with_custom_AMI_128\"></a><strong>Launch EKS cluster with custom AMI</strong></h4>\n<p>You can now make use of the custom AMI for Amazon EKS. In this example, <code>eksctl</code> is used to create the EKS cluster.</p>\n<p>Download and extract the latest release of <code>eksctl</code> with the following command.</p>\n<pre><code class=\"lang-\">$ curl --silent --location &quot;https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz&quot; | tar xz -C /tmp\n</code></pre>\n<p>Move the extracted binary to /usr/local/bin.</p>\n<pre><code class=\"lang-\">$ sudo mv /tmp/eksctl /usr/local/bin\n</code></pre>\n<p>Test that your installation was successful with the following command:</p>\n<pre><code class=\"lang-\">$ eksctl version\n</code></pre>\n<p>Create the <code>cluster.yaml</code> with the custom AMI ID:</p>\n<pre><code class=\"lang-\">apiVersion: eksctl.io/v1alpha5\nkind: ClusterConfig\nmetadata:\n name: managed-cluster\n region: ap-southeast-1\n\nmanagedNodeGroups:\n - name: custom-ng\n ami: ami-0c51983d4f4f751e7\n overrideBootstrapCommand: |\n #!/bin/bash\n /etc/eks/bootstrap.sh managed-cluster\n</code></pre>\n<p>Next, create the cluster with the cluster.yaml as input.</p>\n<pre><code class=\"lang-\">$ eksctl create cluster --config-file=cluster.yaml\n</code></pre>\n<p>The cluster with the hardened AMIs is now ready for use.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/885c87b8805c45c29ad1c72bf31852f0_image.png\" alt=\"image.png\" /></p>\n<p>From the EC2 console, we can see that these custom nodes are using the custom AMI ID.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/2c43d8229c4241ea9a8f4d4f360561be_image.png\" alt=\"image.png\" /></p>\n<h3><a id=\"Summary_180\"></a><strong>Summary</strong></h3>\n<p>In this post, we showed how to build a custom STIG compliant hardened AMI that works with Amazon EKS. We used the Amazon EC2 Image Builder to apply STIG components, installed Kubernetes binaries on the custom AMI and created an EKS cluster with the new AMI. This solution is an option for organizations looking to deploy compliant Amazon EKS environments. The resulting images should still be independently audited and scanned by your internal security organization to ensure they meet the latest standards.</p>\n<p>If you are looking to learn more about Amazon EKS best practices, please check out the <a href=\"https://aws.github.io/aws-eks-best-practices/\" target=\"_blank\">EKS Best Practices Guides</a>.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/125b12c6e067467c8ce7b999f55025fe_image.png\" alt=\"image.png\" /></p>\n<p><strong>Wayne Toh</strong></p>\n<p>Wayne Toh is a Specialist Solutions Architect for Graviton at AWS. He focuses on helping customers adopt ARM architecture for large scale container workloads. Prior to joining AWS, Wayne worked for several large software vendors, including IBM and Red Hat. His hobbies include road cycling and trance music.</p>\n"}