FSI Services Spotlight: Amazon Elastic Container Service (ECS) with AWS Fargate

In this edition of the Financial Services Industry (FSI) Service Spotlight monthly blog series, we highlight five key considerations for customers running workloads on Amazon Elastic Container Service (ECS) with AWS Fargate: achieving compliance, data protection, isolation of compute environments, audits with APIs, and access control/security. Across each area, we will examine specific guidance, suggested reference architectures, and technical code to help streamline service approval of AWS Fargate.

Containers are a powerful way for developers to develop, package, and deploy their applications. At AWS, we have over a hundred thousand active ECS clusters and hundreds of millions of new containers started each week.

Container orchestration solutions like ECS make it easy to manage and scale container workloads. However, AWS customers are still responsible for the underlying infrastructure’s availability, capacity, and maintenance with each of these container management solutions. Amazon ECS enables you to rapidly build applications and grow your business, and reduce time spent on the undifferentiated heavy lifting tasks like configuration, patching, and managing the control plane, add-ons, and nodes.

AWS Fargate is an easy way to deploy containers on AWS. To put it simply, Fargate is like EC2, but instead of giving you a virtual machine, you get an ECS task or EKS pod. The compute engine allows customers to use containers as a fundamental compute primitive without managing the underlying instances. All customers need to do is build their container image, specify the CPU and memory requirements, define networking and IAM policies, and launch a task or pod. More than 50% of new AWS container services customers in 2019 chose Fargate because of its flexibility, per-second billing granularity, and other benefits.

Customers of all sizes are using AWS Fargate at scale. JD Power uses Fargate to power crawlers across their data lake. Many other customers, including Vanguard, Northmill bank, Qoala, and Euler Hermes utilize Fargate to remove the undifferentiated heavy lifting of managing the compute resources. This capability frees them to focus on developing their containerized applications.

Achieving Compliance

Security and compliance are a shared responsibility between AWS and the customer. AWS will operate, manage, and protect the infrastructure that runs the AWS services. The customer’s responsibility is determined by the service selected; the more managed services are used, the less customer configuration is required. As AWS Fargate is an abstracted service, customers are responsible for fewer controls to deploy secure transcription jobs vis-a-vis an Infrastructure service.

Figure 1: AWS Shared Responsibility Model

Figure 1 shows the points at which customers take on responsibility from AWS depending on the chosen service. The left-most stack encapsulates services such as Amazon EC2, and allows customers to implement the most amount of customization in their environments. Naturally, this goes hand-in-hand with the customer having the responsibility of managing more components. AWS Fargate falls in the middle stack of container services. In this stack AWS has increased portion of the shared responsibility when it comes to platform and operating system management. The customer receives out-of-the-box AWS Fargate capabilities, and therefore only needs to configure customer data protection, network traffic protection and Identity and Access Management as well as any additional security controls.

AWS Fargate falls under the scope of the following compliance programs regarding AWS’s side of the shared responsibility model. In the following sections, we will cover topics on the customer side of the shared responsibility model. The compliance programs covered by AWS Fargate include:

1. SOC 1,2,3
2. PCI
3. IRAP Protected
4. ISO/IEC 27001:2013, 27017:2015, 27018:2019, and ISO/IEC 9001:2015
5. OSPAR
6. C5
7. MTCS

Data Protection

Customers need to encrypt data within their ECS on Fargate resources. First, they need to encrypt the data on the ephemeral storage within Fargate containers. Server-side encryption of ephemeral storage in AWS Fargate platform version 1.4 and above is encrypted by default with an industry-standard AES-256 encryption algorithm using AWS Fargate-managed keys. Compliance regulations, such as PCI DSS, require encrypting that data at rest throughout the data lifecycle. Using ECS on Fargate enables customers to avoid managing that encryption on the ephemeral storage.

The second aspect of encryption at rest with ECS on Fargate is encrypting files stored remotely. When reading directly from Amazon Simple Storage Service (S3), customers can utilize S3 server-side encryption such as Amazon S3-managed keys (SSE-S3), AWS KMS keys stored in AWS Key Management Service (KMS) (SSE-KMS). Customers can also use encryption keys (SSE-C) that reside outside of AWS. Another file storage option for ECS on Fargate is Amazon Elastic File Service (EFS). EFS supports transparently encrypting data at rest and during transit. Additionally, existing applications can take advantage of these capabilities without making code modifications. Encryption keys are managed by the AWS KMS, eliminating the need to build and maintain a secure key management infrastructure.

Encryption in transit between clusters and AWS services can utilize default industry-standard Transport Layer Security (TLS) 1.2 encryption in transit for services like S3, EFS, FSx, and many more. If customers need encryption in transit between tasks, they can create private certificates with AWS Certificate Manager Private Certificate Authority (ACM Private CA). This service enables developers to programmatically provision short-lived private certificates within their service mesh to enable encrypted TLS communication channels between tasks within the cluster. Similarly, customers can use ACM in tandem with Application or Network Load Balancers (customers can’t extract keys for public certificates generated by ACM so they need ALBs/NLBs.)

Isolation of compute environments

Customers can use AWS Fargate to run containers without managing servers or clusters of Amazon EC2 instances. Each Fargate task has a VM-encforced isolation boundary and does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with another task.

Customers can apply network-level controls, such as security groups and network ACLs, to their containerized workloads. AWS ECS on Fargate does this by creating an elastic network interface (ENI) in their specified VPC and attaching it to the Fargate managed instance. This gives customers control over the network-level access of the services they run on Amazon ECS. For more information, see Security Groups for your VPC and Network ACLs.

AWS Fargate support for PrivateLink allows you to privately connect your Amazon VPC to AWS Services including Amazon ECR. In addition, you can configure your services running on Amazon ECS and AWS Fargate to leverage PrivateLink to expose an application in a private subnet in a VPC.

Additionally, customers can improve their security posture by attaching a least privilege consistent endpoint policy to their VPC endpoint that controls access to Amazon ECS. These features enable customers to restrict API calls to ECS from only specific caller contexts (e.g., IP-Range filtering). For more information, see the complete list of details and considerations when using VPC Endpoints with ECS.

Automating audits with APIs

Implementing AWS Config rules ensures compliance with specific configurations. AWS Config monitors the configuration of resources and provides some out-of-the-box rules to alert when resources fall into a non-compliant state. Customers can enable AWS Config in their account using the AWS Config console or the AWS Command Line Interface (AWS CLI). They can select the Amazon container resource types for which they want to track configuration changes, such as ECS::Cluster, ECS::Service, ECS::TaskDefinition, and ECR::Repository. AWS Config allows for both managed rules and custom rules, enabling customers to build complex audits given their specific business needs. Some examples of audits on ECS with AWS Config managed rules include:

1. The first is ecs-task-definition-user-for-host-mode-check. It checks if the ECS task definition with host networking mode has ‘privileged’ or ‘user’ container definitions. If privileged=false or empty and user=root or empty, it will fail the check and alert the customer.
2. The second is efs-encrypted-check that checks if EFS will encrypt the file data using AWS KMS. Since ECS commonly uses EFS, we recommend using managed Config rules that audit associated storage.

Customers can view more details on these managed rules here.

Besides managed rules in Config, customers can build custom Config rules using API calls related to ECS recorded by AWS CloudTrail. AWS CloudTrail is an AWS service that helps customers enable governance, compliance, and operational and risk auditing of their AWS account. CloudTrail provides an aggregated repository of AWS API calls and changes to resources for over 160 AWS services. AWS CloudTrail records API calls made to the ECS on Fargate service. Following are a few key APIs across the resource lifecycle to monitor for ECS container instances, to ensure only approved containers are created.

1. The CreateCluster, CreateService, UpdateService, DeleteService, and DeleteCluster API calls control when changes to the ECS execution environment occur. Within each ECS Service, administrators can RegisterTaskDefinition and DeregisterTaskDefinition to revise task definitions.
2. The RunTask, StartTask, and StopTask API calls control launching and terminating ECS on Fargate Task instances. Configure monitoring to ensure the crucial work of developers and operations teams is not abruptly interrupted.
3. Next, Fargate uses the task definition to launch a container instance. The container will transition through lifecycle stages of RegisterContainerInstance, UpdateContainerInstanceState, and finally DeregisterContainerInstance.
4. Administrators can optionally group multiple Fargate tasks into TaskSets. TaskSets have lifecycle operations including CreateTaskSet, UpdateTaskSet, and finally DeleteTaskSet.

Monitoring these APIs in CloudTrail ensures that only appropriate actions are taking place against the customer’s ECS on Fargate container instances. For a complete list of ECS APIs, including but not limited to Fargate container instances, review the Amazon ECS API Reference.

Here is an example of what a CloudTrail log entry looks like for the CreateCluster API:

{ "eventVersion": "1.04",
    "userIdentity": {"type": "AssumedRole",
        "principalId": "AIDACKCEVSQ6C2EXAMPLE:account_name",
        "arn": "arn:aws:sts::123456789012:user/Mary_Major",
        "accountId": "123456789012",
        "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
        "sessionContext": {"attributes": {"mfaAuthenticated": "false",
                "creationDate": "2018-06-20T18:32:25Z"
            },
            "sessionIssuer": {"type": "Role",
                "principalId": "AIDACKCEVSQ6C2EXAMPLE",
                "arn": "arn:aws:iam::123456789012:role/Admin",
                "accountId": "123456789012",
                "userName": "Mary_Major"
            }
        }
    },
    "eventTime": "2018-06-20T19:04:36Z",
    "eventSource": "ecs.amazonaws.com",
    "eventName": "CreateCluster",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "203.0.113.12",
    "userAgent": "console.amazonaws.com",
    "requestParameters": {"clusterName": "default"
    },
    "responseElements": {"cluster": {"clusterArn": "arn:aws:ecs:us-east-1:123456789012:cluster/default",
            "pendingTasksCount": 0,
            "registeredContainerInstancesCount": 0,
            "status": "ACTIVE",
            "runningTasksCount": 0,
            "statistics": [],
            "clusterName": "default",
            "activeServicesCount": 0
        }
    },
    "requestID": "cb8c167e-EXAMPLE",
    "eventID": "e3c6f4ce-EXAMPLE",
    "eventType": "AwsApiCall",
    "recipientAccountId": "123456789012"
}

Additionally, customers can utilize Amazon ECS Exec to access their containers on AWS Fargate. This enables users to either run an interactive shell or a single command against a container without the need to Secure Shell (SSH) into individual containers.

Operational access control and security

When customers are securing their ECS on Fargate cluster, they want to consider three areas to create Least- Privileged IAM roles:

1. Task Execution Role
2. Task Role
3. Cluster Management Role

The Amazon ECS task execution role grants the Amazon ECS container and Fargate agents permission to make AWS API calls on your behalf. Permissions that are needed before the task starts should be contained within the task execution role. Examples are pulling container images, sending container logs to CloudWatch Logs using the awslogs log driver from an Amazon ECR private repository, or referencing sensitive data using Secrets Manager secrets. Customers can create their own task execution role or use the AmazonECSTaskExecutionRolePolicy managed role for ECS Tasks. Customers can edit or alter the task execution role depending on their use case, as shown here.

The Amazon ECS task role grants permissions that can be used by the containers in a task. Permissions that are needed after the task starts (by the application) should be contained within the task role. Examples are providing access to specific objects in S3 or granting write access to certain DynamoDB tables. A benefit of using task roles is that containers can only retrieve credentials for the IAM role that is defined in the task definition to which it belongs; a container never has access to credentials that are intended for another container that belongs to another task.

The guidance to follow with task roles is to ensure that each Task is only authorized to access precisely the API calls to other AWS services it needs. For example, suppose one Task is reading from S3 and writing to a shared SQS queue. In that case, customers should only allow s3:PutObject and sqs:SendMessage on the respective resources (e.g., Bucket arn:aws:s3:::test/* or Queue arn:aws:sqs:*:123456789012:MyCompanyQueue). Limiting the Task role privilege to only what is essential will limit the possibility of data exfiltration or escalation of privilege within the Task in their cluster.

The Cluster Management role is the IAM role federated by an authorized user within the customer’s organization to access the ECS cluster. Administrators should separate this into two primary personas – AdminRole and DeveloperRole. The AdminRole will be more permissive, allowing ECS actions such as CreateCluster and DeleteCluster. Meanwhile, the DeveloperRole can be more scoped down depending on the use case and may exclude DeleteCluster, but include UpdateTaskSet, CreateService, CreateTaskSet, and DescribeClusters. Customers should also utilize Attribute-Based Access Control (ABAC) to authorize not by identity but rather by resource tag. So as an example, customers may want Developer Team A to only access clusters tagged with Team=A. ECS allows them to enable this type of authorization to further scope down which resources individuals can access.

Furthermore customers should consider utilizing Service control policies (SCPs) within AWS Organizations. SCPs offer central control over the maximum available permissions for all accounts in the customer’s organization. Unlike IAM Roles, SCPs are guardrails, which allow customers to set the maximum privilege within an account or set of accounts regardless of the IAM roles created within them. An example might be limiting the creation of ECS clusters to only within a specific region(s) where the customer operates.

Conclusion

In this post, we reviewed Amazon ECS on AWS Fargate container instances, highlighting essential information that can help FSI customers accelerate the service’s approval within these five categories: achieving compliance, data protection, isolation of computing environments, automating audits with APIs, and operational access and security. While not a one-size-fits-all approach, the guidance can be adapted to meet the organization’s security and compliance requirements. It also provides a consolidated list of crucial areas for ECS on Fargate containers.

In the meantime, be sure to visit our AWS Industries blog channel and stay tuned for more financial services news and best practices.