Continuing from the previous blog post, today’s post takes us to Identity and Access Management (IAM) roles for ECS/EKS Tasks. Keeping the principle of least privilege in mind, it is important to understand the difference between Task Roles and Service Roles in securing your containerized workloads. Too many times I have seen the right permissions used for Service Roles and the assumption is thats the permissions set, yet root permissions is then used for tasks.

IAM roles play a role in governing permissions and access within the AWS ecosystem. In the context of ECS and EKS, IAM roles are assigned to tasks, delineating the scope of actions a container can perform and the AWS resources it can access. This limits permissions to only what is necessary for a task’s functionality.

Task Roles

Task Roles are IAM roles attached to individual ECS or EKS tasks. They define the permissions granted to containers within a specific task, influencing their interactions with AWS services and resources.

For example this can be granting read/write access to an S3 bucket, or allowing a container to interact with a DynamoDB table, or more commonly and something which should be set is to allow pushing logs to Amazon Cloudwatch.

Task Roles follow the principle of least privilege by allowing you to tailor permissions to the specific needs of individual tasks, reducing the risk associated with excessive permissions.

Service Roles

Service Roles, on the other hand, are IAM roles associated with ECS services or EKS pods. They define the permissions required by the underlying infrastructure, such as Auto Scaling or Elastic Load Balancing, to manage and scale tasks.

Service Roles streamline the management of underlying infrastructure, ensuring that ECS services and EKS pods have the necessary permissions for orchestration and scaling activities without exposing unnecessary privileges.

Best Practices

So what are the best practices for Task and Service Roles?

Adhere to the Principle of Least Privilege

Tailor IAM roles to grant the minimum permissions necessary for tasks and services to function, it can be painful but start with the minimum required permissions and then add required permissions. As I mentioned before I have seen development teams struggle with this and just to get thing working open everything.

Regularly Review and Update Roles

Periodically assess and update IAM roles based on evolving application requirements and security policies. This ensures that roles align with the dynamic nature of containerized environments, adapting to changing security needs.

Leverage AWS Managed Policies

Utilize AWS Managed Policies to simplify role management and align with AWS best practices. This streamlines the assignment of common permissions, reducing the complexity of role configuration.

Monitor and Audit Role Activity

Implement logging and monitoring for IAM role activity to detect and respond to potential security incidents. This enhances visibility into role usage, aiding in the identification of anomalous behavior and potential threats.

What about the container itself?

Start with a minimal base image for your containers. Images like Alpine Linux or other “slim” variants are designed to be lightweight, with fewer components and a reduced attack surface.

Avoid the Root User!

It’s a best practice to avoid running processes as the root user within your containers. Instead, create and use non-root users for running applications. Many official Docker images provide a non-root user by default.

In your Dockerfile, use the USER directive to set a non-root user for the container. For example:

FROM alpine:latest
...
USER nonrootuser

User namespaces also allow containers to run with a different user and group ID inside the container than on the host system. This helps in minimizing the privileges of processes within the container.

Only grant the necessary permissions to the user within the container. If the application doesn’t require root privileges, don’t provide them. This follows the principle of least privilege.

Docker supports Linux capabilities, which can be used to granularly provide specific privileges to a container. Additionally, AppArmor and SELinux profiles can be used to enforce security policies on container processes.

Keep your base images up to date. Regularly check for security updates and patches for the OS and any installed software within the container. Use container security tools and scanners to audit your container images for vulnerabilities and adherence to security best practices.

If you are using container orchestration platforms like Kubernetes, leverage security policies to enforce best practices, such as preventing containers from running as the root user.