Security

The shared responsibility of security applies to AWS container services as well. AWS manages the security of the infrastructure that runs your containers. However, controlling access for your users and your container applications is your responsibility as the customer. AWS Identity and Access Management (IAM) plays an important role in the security of AWS container services. The permissions provided by the IAM policies attached to the different principals in your AWS account, determines what capabilities they have. You should avoid using long-lived credentials such as access keys and secret access keys with your container applications. IAM roles provide you with temporary security credentials for your role session. You can use roles to delegate access to users, applications, or services that don't normally have access to your AWS resources. There are usually IAM roles at two different levels. The first determines what a user can do within AWS Container services, and the second is a role that determines which other AWS services your container applications running in your cluster can interact with. For Amazon EKS, the IAM roles works together with Kubernetes RBAC to control access at multiple levels. IAM roles for service accounts (IRSA) with Amazon EKS, enables you to associate an IAM role with a Kubernetes service account. This service account can then provide AWS permissions to the containers in any pod that uses that service account.

With this feature, you no longer need to over-provision permissions to the IAM role associated with the Amazon EKS node, so that pods on that node can call AWS APIs.

Similarly, you can employ principles of least privilege by assigning granular IAM roles to Amazon ECS tasks. Assigning each Amazon ECS task a role aligns with the principle of least privileged access and allows for greater granular control actions and resources.

For your audit needs, you can use AWS CloudTrail, a service that provides a record of actions taken by a user, role, or another AWS service in AWS container services. Using the information collected by CloudTrail, you can determine the request made to Amazon ECS, the IP address from which the request was made, who made the request, when it was made, and additional details. For Amazon EKS, enabling control plane logging gives you the ability to trace calls to the Amazon EKS control plane. The audit logs are sent to Amazon CloudWatch Logs. You can configure the containers in your Amazon ECS tasks to send log information to CloudWatch Logs. For intelligent threat detection, Amazon GuardDuty EKS audit log monitoring and Amazon EKS runtime protection can be used to detect threat actors inside your Amazon EKS clusters.

AWS Secrets Manager and AWS Systems Manager Parameter Store are two services that can be used to secure sensitive data used within container applications. Systems Manager Parameter Store provides secure, hierarchical storage of data with no servers to manage. Secrets Manager provides additional capabilities that includes random password generation and automatic password rotation. Data stored within Systems Manager Parameter can be encrypted using AWS KMS and Secrets Manager uses it to encrypt the protected text of a secret as well. AWS container services can integrate with either Systems Manager Parameter Store or Secrets Manager to process sensitive data securely. Secrets Manager, however, also includes the ability to automatically rotate secrets, generate random secrets, and share secrets across AWS accounts. Kubernetes secrets enables you to store and manage sensitive information, such as passwords, docker registry credentials, and TLS keys using the Kubernetes API. Kubernetes secrets are, by default, stored as unencrypted base64- encoded strings. They can be retrieved in plain text by anyone with API access, or anyone with access to Kubernetes' underlying data store. You can apply native encryption-at-rest configuration provided by Kubernetes to encrypt the secrets at rest.

However, this involves storing the raw encryption key in the encryption configuration, which is not the most secure way of storing encryption keys. Kubernetes stores all secret object data within etcd, encrypted at the disk level using AWS-managed encryption keys. You can further encrypt Kubernetes secrets using a unique data encryption key (DEK). You are responsible for applying necessary RBAC based controls to ensure that only the right roles in your Kubernetes cluster have access to the secrets and the IAM permissions for the AWS KMS key is restricted to authorized principals.

The container services take advantage of different constructs provided by Amazon VPC. By applying right controls for IP addresses and ports at different levels, you can ensure that only desired traffic enters and leaves your container applications. In Amazon EKS and Amazon EKS Anywhere, restricting network traffic between pods can be achieved by implementing network policies in your clusters. Network policies give you a mechanism to restrict network traffic between pods (often referred to as east/west traffic) and between pods and external services. You can now use Amazon VPC CNI to implement both pod networking and network policies to secure the traffic in their Kubernetes clusters. Alternately, you can also use security groups for pod feature in Amazon EKS and Fargate on Amazon EKS if you need to control communication between services that run within the cluster and service the run outside the cluster such as an Amazon RDS database. With security groups for pods, you can assign an existing security group to a collection of pods.

Encrypting network traffic prevents unauthorized users from intercepting and reading data when that data is transmitted across a network. For encrypting traffic in transit, you can use service mesh like App Mesh with Amazon ECS and Amazon EKS. With App Mesh, you can configure TLS connections between the Envoy proxies that are deployed with mesh endpoints. You can also use AWS PrivateLink to access your Amazon ECS and Amazon EKS clusters more securely without the need to go over the internet.

Container image is considered the first line of defense against an attack. An insecure, poorly constructed image can allow an attacker to escape the bounds of the container and gain access to the host. To prevent this from happening, you should create minimal container images or use distro-less images. Also, use multi-stage builds and linting tools in your Docker files. In addition, you can use Amazon ECR’s basic and enhanced scanning features to continuously scan your container images for any security vulnerability. Also, use immutable tags with Amazon ECR. Immutable tags force you to update the image tag on each push to the image repository. This can prevent attackers from overwriting an image with a malicious version without changing the image's tags. Additionally, it gives you a way to easily and uniquely identify an image. Signing your container images that you store in Amazon ECR establishes authenticity and provenance, giving you the ability to determine if content comes from a particular party. You can use AWS Signer Container Image Signing capability for signing and verifying container images stored in Amazon ECR.

To implement stricter security controls across applications that run in your Amazon EKS cluster, use Policy-as-Code (PAC) solutions like Open Policy Agent (OPA) that provide guardrails to guide cluster users, and prevent unwanted behaviors, through prescribed and automated controls. Alternatively, you can also use Pod Security Standards (PSS) and Pod Security Admission (PSA), which come built into Kubernetes 1.25 onwards and are supported by Amazon EKS. While using Amazon EKS and Amazon ECS, restrict containers that can run with privileged access. Containers that run as privileged inherit all the Linux capabilities assigned to root on the host. Running a container as privileged isn't supported on Fargate.

For securing your infrastructure, consider using Amazon ECS optimized AMIs, Amazon EKS optimized AMIs, and Bottlerocket. They contain a minimal set of OS packages and binaries necessary to run your containerized workloads. They provide a smaller attack surface, which reduces the chances of your instances being compromised by questionable packages and modules. You can run Amazon Inspector to assess hosts for exposure, vulnerabilities, and deviations from best practices.