Microservices Security: AWS Increases Container-Enabled App Security

As AWS experts we work closely with organizations who handle a wide variety of sensitive information – from patient health records to credit card data and more. Resultantly, we are always on the look-out for technology and best practice-based improvements to ensuring cloud-based security. With more and more of our clients looking to embrace a microservices architecture, cloud security and compliance naturally didn’t stop being a focus which is why we are happy at the news from AWS today that they’ve addressed how to help secure container-enabled applications with IAM Roles for ECS tasks.

To give you a little background, in Amazon ECS, users have always been able to use IAM roles for Amazon EC2 in order to simplify API requests from containers. With roles you can build systems for secret management using ECS and Amazon S3 or use S3 to store artifacts generated by your containers. This is a good approach as it allows you to avoid storing your AWS credentials in your code or your configuration files. And, it also allows you to benefit from automatic key rotation.

However, the downside of this approach for organizations with container-based apps soon became clear: the policies assigned to the EC2 instances in an ECS cluster had to be all-inclusive. That is, your policies had to cover each and every task performed within that cluster.

A security best practice that our AWS consultants subscribe to is that of least privilege.  Applicable to not just people, but programs and processes, least privilege seeks to establish the minimum level of permissions, for example, needed to still perform a task with its desired outcome. Whereas before a user might have to assign multiple permissions to the same EC2 instance for different containers with vastly different needs, with the introduction of IAM roles for ECS tasks, you can now directly assign the IAM role to the ECS task.

In addition, according to AWS, the update also allows you to use a minimal IAM policy for the ECS cluster instances because you only need to give the tasks a few required IAM permissions to interact with the ECS service.

While working with an East Coast based healthcare startup this spring, we felt the dire need for this feature as the customer wanted compete isolation of control between services for compliance and security reasons. With this feature missing, they had to resort to using one ECS cluster per microservice, essentially reducing the value of ECS and container-based microservices.

However, with this new feature, they can now consolidate their services on the same ECS cluster while maintaining the same level of security. Thus, achieving a reduction in cost and management overhead with no compromise in security.

Similarly, in working recently with a marketing analytics startup, we encountered the same problem. This customer had us set-up HashiCorp Vault and its AWS Secret Backend. The customer modified their code to query Vault for least privilege AWS credentials. Not all customers have the flexibility to modify code and for such customers this feature is extremely useful as it can allow code written with AWS SDKs to work in the container securely out of the box.

Microservices provide an inherent level of risk mitigation due to the fact that they are container based, feature the ability to easily rollback if needed, and if a microservice were to fail, other services would continue running, providing greater system resilience. Today’s announcement that provides more granular policy application for greater control grows security best practices for container based apps.

If you have questions about securing a microservices architecture, please reach out today as our AWS experts are happy to share how our cloud security best practices can benefit your organization.

Did you find this useful?  

Interested in getting tips, best practices and commentary delivered regularly? Click the button below to sign up for our blog and set your topic and frequency preferences.