Hardened STIG EKS builds

[mebays]

I have been issued the request of creating a custom image based on the CIS Amazon Linux 2 STIG Benchmark image.

Some things that have been discovered:

• The additional filesystems that are required (/var, /var/log, /var/log/audit) cause issues after joining due to ephemeral storage.

  • The containerd process and kubelet will end up logging into these filesystems and majority of ephemeral storage if not using additional tools.
  • Is there going to be a way in the future to add custom scripts?
    • This could be used to revert the file system to the suggested one volume.
    • I came along the hobbsh/hardened-eks-ami repo where a majority of this is copied and then additional scripts are added. I'm not suggesting using ansible but having some method to add additional scripting would be nice. It could be used to revert hardened images or add hardening scripts.

• After successfully building an eks STIG fips hardened image. I notice a serious lag in the joining of the cluster. (approximately 3-4 minutes from boot time to when it appears from kubectl get nodes)

  • Is there any suggestion on how to track down what is causing the slow start up?

Question:

• With the complexity of hardened images and custom builds. Will there ever be a scenario where a hardened EKS image is published?
  • This would be useful for environments with high security standard (e.g. fedRAMP environments).
• In modifying this repo, will there ever be a shift to using hcl syntax over json?
  • The hcl syntax is fairly straight forward and could allow those that want to use al2 and al2024 to leverage packers parallel build process. (Mostly curiousity as it does make things easier to read, more flexible, and less duplication)

[zhuoweilee]

The node ready delay may be caused by SELinux policies that should be resolved with #1773