Getty Images/iStockphoto
3 AWS container security best practices
Security is crucial for container-based applications. Learn how to protect AWS container environments with best practices for ECS, EKS and the extension for on-premises deployments.
Security is a key component in any infrastructure, and AWS containers are no exception.
AWS containers use a shared responsibility model. The cloud container provider and its customer are in charge of different aspects of the stack. AWS makes its containers fairly secure on its cloud infrastructure, but it is up to the cloud administrator using the containers to secure applications and workloads.
AWS has two main container offerings:
- Amazon Elastic Container Service (ECS). A fully managed container orchestration service to deploy and manage containerized applications.
- Amazon Elastic Kubernetes Service (EKS). A fully managed service to build, secure and maintain Kubernetes clusters on AWS.
Both are secure and are almost interchangeable, but ECS offers a more tightly controlled, safe environment. While most security options from AWS apply to both offerings, the provider recommends that people new to AWS-hosted containers should start with ECS.
Whichever service you choose, follow AWS container security best practices for:
- account management
- image availability
- secrets management
Secure account management
Account roles and proper separation of duties are key to any security strategy. AWS manages all accounts via the AWS Identity and Access Management (IAM) service. IAM is included in the AWS account. The cloud admin can create and manage AWS users and groups, and restrict access to AWS resources. To get the most out of IAM, use these best practices.
Roles and permissions ensure users can only access data they're authorized on. Entry-level employees should not need access to sensitive financial documents, for example, so ensure they cannot accidentally damage this data by setting appropriate restrictions.
When setting up permissions, don't grant direct permanent assignments of access. It leads to unwieldly account management.
Turn two-factor authentication on for all accounts. It is unlikely that intruders can take over and steal sensitive data when you require two forms of proof that they are the authorized user.
Image availability and security
AWS ECS and EKS users must pay close attention to what they import into a container, since it affects the deployment's overall security.
Admins and developers can't just trust the latest pull from a public container repository. Use a trusted repository of known-good code. Pulling anything directly from the internet introduces several issues, such as being unable to guarantee a resource, such as a file or program, is available. Even if it is available, the code could have changed since the last time it was pulled into an image, and could cause unexpected behavior or issues.
Node.js users faced an example of this unavailability on a large scale in 2016. A developer unpublished his 17-line Node Package Manager package called left-pad. All the applications and programs that used left-pad over the internet were thereafter unable to run the code correctly. The Node.js team had to replace the deleted code with a backup. That event proved how dangerous it is to assume an important file will always be available when you call for it.
In the same vein, be careful about base images. Build all production containers from official, vendor-provided base images. Ensure the pulled application is trusted and not compromised.
For any container that involves mission-critical or sensitive data, use a trusted code repository. AWS provides its own secure image repository, Amazon Elastic Container Registry (ECR), which works with both ECS and EKS.
Keep your secrets secret
Secrets management best practices should be enforced with developers. Don't take risks with account passwords, API authorizations and other secrets in the code of the containerized application.
To prevent security issues in your environment, consider AWS Systems Manager Parameter Store. The parameter store is a secure, encrypted repository for configuration data management and secrets management.
IT teams can tag data within the parameter store and use different credentials for different environments. For example, administrators can use one set of credentials for production and one for development. All it takes to implement a specific configuration -- in terms of access keys, API keys and more -- is to tell the instance or service to use the appropriate tag at runtime.
IT teams must refactor processes and code to use the parameter store. Due to this step, it may take a little time to get running properly. However, in the long run, the containerized code base will be more dynamic to use.
ECS/EKS Anywhere
In 2021, AWS released extensions to its container services, dubbed ECS Anywhere and EKS Anywhere. These extensions enable AWS customers to deploy native Amazon ECS tasks in AWS-managed or internally managed infrastructure. ECS/EKS Anywhere security is more complicated than standard AWS container deployments. These two services can run in an on-premises environment, but in a way similar to that of native AWS services. From a security perspective, the responsibility model changes slightly.
The control plane extends to on-premises, but it is managed from the AWS environment and talks to on-premises servers via an installable client, the Amazon ECS agent. Onsite hardware is the administrator's responsibility to patch and manage, unlike native ECS on AWS servers. Note that the best practices mentioned above applies to these extensions as well.
