Running AWS EKS in FedRAMP Environments
Running AWS EKS in FedRAMP Environments
As containerization becomes standard in modern cloud architectures, I’ve seen a growing number of FedRAMP-authorized systems incorporating Kubernetes into their environments. Amazon Elastic Kubernetes Service (EKS) offers a managed solution that can work well for FedRAMP, but it comes with some specific compliance challenges.
Having helped organizations navigate this process, I wanted to share some practical guidance for security and platform teams implementing EKS in FedRAMP environments.
When introducing EKS to a FedRAMP environment, you’ll need to update a wide range of controls in your System Security Plan (SSP). You can use AWS Customer Compliance Guides to help you understand your obligations around EKS and FedRAMP from a specific control mapping perspective. But rather than listing every control, let’s focus on the ones that require the most technical effort.
Here’s what I’ve found requires the most attention:
STIG Hardening
STIG hardening for EKS environments addresses configuration management controls CM-2 (Baseline Configuration) and CM-6 (Configuration Settings).
STIG AMIs
Worker node security is critical for EKS in FedRAMP environments. AWS’s guide on building STIG-compliant AMIs for EKS is a great starting point, but you’ll need to operationalize this.
I recommend ensuring that you have a well-defined process for spinning up EKS clusters using Infrastructure as Code rather than the AWS console. This could involve a process like:
- Setting up an automated AMI building pipeline using AWS Image Builder with the STIG components
- Implementing testing (e.g OpenSCAP) to verify STIG compliance before deployment
- Using managed node groups with these custom AMIs for easier updates
The hardest part is maintaining compliance through updates. Blue/green deployments for node groups can help, allowing you to validate compliance before shifting workloads.
STIG containers
Securing the EC2 AMIs that underly the EKS cluster is only half the battle. Your container images also should be STIG hardened for FedRAMP compliance. As outlined in Chainguard’s approach to STIG hardening container images, there are several key considerations:
- Minimize the attack surface by using distroless or minimal base images
- Remove unnecessary packages, shells, and utilities
- Eliminate package managers from production containers
- Use multi-stage builds to separate build dependencies from runtime images
- Implement least privilege by running as non-root users
- Remove setuid/setgid binaries from container images
- Set file permissions correctly within the container
I recommend implementing these practices in a formal container image building pipeline.
FIPS Encryption
FIPS encryption implementation satisfies cryptographic requirements in NIST 800-53, specifically SC-13 (Cryptographic Protection) and SC-28 (Protection of Information at Rest).
FIPS 140-2/3 compliance might be the trickiest part of running EKS in FedRAMP. There’s considerable confusion about how FIPS works in a cloud environment, particularly in understanding what falls on your side of the shared responsibility model. As I described in my article on Meeting the FedRAMP FIPS 140-2 Requirement on AWS, FIPS compliance needs to be addressed at different layers.
Be prepared to explain your approach to auditors using your SSP and Cryptographic Modules Tables, linking to CMVP IDs - they’ll want to understand:
- Your defined cryptographic boundary
- Which components use FIPS-validated modules
- Your compensating controls for non-compliant components
- Your risk acceptance process for any gaps
AWS FIPS endpoints
Use FIPS endpoints for all AWS API calls including EKS API by configuring your AWS CLI and SDKs to use these endpoints by default.
FIPS AMIs
- Choose FIPS-capable AMIs for your worker nodes (Ubuntu Pro, RHEL, etc.)
- The AWS GitHub issue shows AWS recognizes the challenges but hasn’t provided a comprehensive solution, especially at the container level.
- Enable FIPS mode in the operating system
- For Amazon Linux 2, enable FIPS mode with packages like dracut-fips
- For Red Hat or Ubuntu Pro, follow vendor-specific FIPS enablement steps
FIPS containers
- This is where things get complicated - container images often lack FIPS validation
- Consider using base images from vendors that provide FIPS-compliant container images
- Document which containers can and cannot use FIPS-validated modules
- Implement compensating controls for non-compliant components
Vulnerability Management
Satisfying FedRAMP vulnerability scanning requirements (RA-5) requires scanning at both the OS and container-level.
Vulnerability Mangement for EC2
For EKS, vulnerabiltiy scaninng starts with the EC2 instances serving as worker nodes. These instances need traditional vulnerability scanning approaches that integrate well with your FedRAMP boundary.
Amazon Inspector is particularly well-suited for this task as it’s already included in AWS’s FedRAMP authorization package. This means its findings can be incorporated into your continuous monitoring automation with straightforward AWS native integrations.
Vulnerability mangement for containers
FedRAMP vulnerability scanning requirements get interesting with containers because they’re typically ephemeral. You need to know what’s running and scan both container images and running containers. My suggestion here:
- Build an automated inventory collection process that queries the EKS API to list all running containers.
- Re-publish those containers to Amazon ECR in an account that is part of the authorization boundary in a repository that is used just for vulnerability scanning.
- Configure ECR scanning on every image push for that repository.
- Generate reports showing vulnerability status of all running workloads and assign them to the team responsible for updates, along with FedRAMP-derived due dates.
Identity and Access Management
EKS introduces a dual authentication/authorization model that needs careful design:
- You’ll use AWS IAM for authentication to your Kubernetes cluster
- Kubernetes RBAC controls authorization once you’re in the cluster
This maps to controls AC-2, AC-3, AC-5, and AC-6, and requires specific implementation. The key principle here is implementing least privilege across pods using IAM Roles for Service Accounts rather than assigning broad permissions at the node level.
Logging and Auditing
FedRAMP auditors love logs. For EKS, you’ll need to enable all five EKS control plane logs to satisfy AU-2, AU-3, and AU-12:
- API server logs (api)
- Audit logs (audit)
- Authenticator logs (authenticator)
- Controller manager logs (controllerManager)
- Scheduler logs (scheduler)
Make sure these logs flow to your other FedRAMP-approved logging destinations and that you’ve set up retention periods matching your FedRAMP requirements (typically 90 days online, 1 year offline).
Security Monitoring
For SI-4 and related controls, GuardDuty’s EKS protection capabilities are worth enabling.
Secrets Management
For SC-28 compliance, you need to encrypt Kubernetes secrets. EKS makes this straightforward. Consider also using AWS Secrets Manager with the AWS Secrets and Configuration Provider (ASCP) for Kubernetes to manage sensitive information more securely.
Running EKS in FedRAMP environments is useful, but requires careful planning and implementation. In my experience, the most challenging aspects are:
- FIPS compliance across multiple interfaces
- Continuous vulnerability scanning and remediation for EC2 instances and containers
- STIG hardening for AMIs and containers base imagess
I’ve found that addressing these challenges early in your design process makes the FedRAMP assessment go much more smoothly. Document your approach thoroughly, and be prepared to explain your design decisions to auditors.
Have you implemented EKS in a FedRAMP environment? What challenges did you face? I’d love to hear about your experiences.