AWS Fargate offers an attractive way to run container workloads for customers with compliance requirements, as it shifts the responsibility of managing the underlying host to AWS. This means that customers are relieved of typical responsibilities like host hardening, patching, and endpoint protection.
In some cases, however, host configuration may be required to meet regulatory compliance requirements. Customers building FedRAMP workloads, for example, need to enforce the usage of cryptographic modules validated by Federal Information Processing Standards (FIPS). In GovCloud (US), Amazon ECS on AWS Fargate supports a “FIPS mode” setting to support deploying workloads in a manner compliant with FIPS 140.
How Fargate FIPS mode helps
The account-level setting fargateFipsMode configures all ECS tasks running on Fargate to:
- Direct ECS and Fargate service communication through FIPS-compliant endpoints
- Enable only FIPS-validated cryptographic modules
- Boot the underlying kernel in FIPS mode
Note: ECS tasks must use the Linux platform (Windows is not supported), and an x86_64 CPU architecture (ARM64 is not supported).
Enabling this configuration requires only a single command, and applies to the entire AWS account.
Remaining customer responsibilities for FIPS compliance
While Fargate FIPS mode enables customers to use Fargate in a FIPS-compliant manner, there are additional customer responsibilities to keep in mind.
Use FIPS endpoints when interacting with other AWS services
Customers must configure applications to interact with other AWS services using FIPS endpoints. The easiest way to do this is by leveraging AWS SDKs and setting the appropriate environment variable, e.g. AWS_USE_FIPS_ENDPOINT. For example, if your application uploads an object to Amazon S3, it will communicate through s3-fips.us-east-1.amazonaws.com instead of s3.us-east-1.amazonaws.com.
Encryption in transit of traffic from public clients
Public endpoints need to present a public certificate that clients will trust, usually on a load balancer with a certificate provisioned by AWS Certificate Manager (ACM). AWS Elastic Load Balancing (ELB) offers TLS support on both Network Load Balancers (NLB) and Application Load Balancers (ALB). Customers must configure HTTPS listeners to use the appropriate FIPS 140 validated policies.
While NLBs and ALBs handle TLS differently, both can support encryption all the way to the container. NLBs pass TLS traffic through, where the target containers perform TLS termination with a publicly trusted certificate. ALBs terminate TLS connections with a public certificate and can be configured to establish a new TLS connection with the downstream targets. ALB doesn’t validate the target certificates.
Encryption in transit of inter-service communication
AWS encrypts all network traffic between AWS regions and Availability Zones (AZs). Traffic within an AZ is private and secure, but is not necessarily encrypted. To ensure cryptographic protection of internal communications, customers can deploy a service mesh or configure TLS connections within their applications.
AWS offers managed service mesh options, including VPC Lattice, ECS Service Connect, and App Mesh, but these are not currently available in GovCloud. Customers can build and deploy Envoy proxy in a FIPS-compliant mode if desired.
Many customers prefer to handle TLS connections within their applications. Containers will need an appropriate TLS certificate available, which can be generated by AWS Private CA or acquired from a trusted SSL/TLS certificate provider Then the container’s listener must be configured with that certificate and to not accept unencrypted traffic.
Encryption of ECS task data
ECS tasks commonly attach storage volumes from Amazon Elastic Block Store (EBS) or Elastic File Service (EFS). Customers must configure these storage services for encryption at rest and in transit when creating the resources, and when attaching them to your ECS tasks
ScaleSec builds compliant architectures
Contact ScaleSec for help building or migrating your regulated workloads.