Securing your containers on AWS is an essential part of your management under the AWS Shared Responsibility model. Specifically, securing them will enable you to protect everything IN the cloud, while AWS protects the security OF the cloud.
Containers are deployable anywhere and provide improved efficiency, portability, and scalability compared to virtual machines. This flexibility allows you to streamline the application development process.
However, flexibility comes at a cost. It opens up a number of new attack vectors that can be exploited by a clever attacker. These range from the images used to build your containers, the registries used to store these images, the container runtimes themselves, and even the host OS that manages the docker client can be exploited.
That might sound concerning, but don’t worry; you can mitigate this risk by establishing a strong AWS container security strategy, and that’s exactly what this guide will help you do. We will explain the steps you need to take in order to build a robust strategy to secure your containers on AWS, and walk you through some common challenges you may face, and how to overcome them.
Ready? Then let’s dive in.
Step 1: Optimize your IAM Management Strategy To Zero-Trust protocols
The easiest way to drastically reduce your attack surface is by properly controlling user permissions. Approximately 85% of all data breaches involve some kind of human engineering attack. By limiting the access each user has to your AWS installation, you reduce the damage that they can do if their account becomes compromised in a phishing attack.
The first way to secure your containers is to adopt a zero-trust security design, embodying the principle of Never Trust, Always Verify. This approach assumes that every user could be compromised, and therefore must be challenged to prove they are who they claim to be.
The best way to do this is to design your AWS Identity and Access Management (IAM) IAM policies with the zero-trust model in mind. Doing this on a task level would be burdensome, so it is recommended that you create policies that apply at the cluster level to provide a nice compromise between security and administrative overheads. As a general rule, you should always avoid giving containers privileges that they do not need.
As a final, but essential, security measure, you should implement two-factor authentication. This helps to ensure that if an attacker does gain access to someone’s account, they can’t actually do anything without revealing themselves.
One important thing to keep in mind is that you should avoid allowing containers to inherit role assignments. Instead, you should create purpose built ECS IAM roles for each cluster or container to avoid accidentally creating attack vectors through automation.
Step 2: Implement Robust Real Time Network/Runtime Security
Once you’ve properly configured your IAM, the next step is to start monitoring your containers for security breaches in real time. The easiest way to do this is to implement runtime security, which provides active protection for your containers while they’re running by detecting and preventing malicious activity in real time. In general, utilizing AWS containers will immediately help improve the security of your implementation, but there are minor differences between Windows and Linux containers.
While Windows Server and Linux containers share similar degrees of isolation, developers must assume that any attack can be performed via an elevated process regardless of operating system. If the kernel is compromised, then so is every container sharing that kernel.
How exactly you implement container runtime security will differ depending on whether you are running Windows, or Linux containers:
Windows Containers:
Windows containers are managed by Microsoft, and in order to properly secure your containers Microsoft strongly recommends that you utilize hypervisor-isolated containers to provide adequate security, particularly in a multi-tenant environment.
In order to follow the principles of zero-trust, it is also recommended that you run all containers with a ContainerUser account, and not a ContainerAdmin account. This prevents a malicious actor from mounting the .ssh folder and adding a public key.
Linux Containers:
It generally isn’t enough to use sec comp to secure a Linux container, as this solution cannot isolate containers from each other. Instead, it is recommended that you use the AppArmor security module, using a third party tool like bane in order to build the AppArmor profile. If you are unfamiliar with Linux installs you can use a third party app from the Amazon store (with our help you can even use AWS credits to pay for it! Find out how).
Step 3: Efficiently Implement Secrets Management
Proper secrets management is an invaluable way to help secure your AWS containers. AWS Secrets Manager helps to protect sensitive data, such as passwords and API keys. This is useful because you can use the Secrets Manager itself as a secure storage solution, as opposed to baking them into the container.
You can also use the Secrets Manager Parameter Store to encrypt information, or generate new keys and credentials which can be shared between multiple accounts, without giving those accounts access to the manager.
For example, IT teams can tag data and use different credentials for different environments. This can give administrators one set of credentials for production, and one for development. Even if one set of keys is compromised, the attacker would only be able to access one aspect of an administrator’s responsibilities.
You should also use the manager to regularly remove any unused keys, and ensure that you regularly rotate them if possible, eliminating potentially compromised keys. To help you do this, it might make sense to look at third-party tools for secrets scanning, which can flag potential problem-points.
Step 4: Ensure Strong Data Protection & PCI Compliance
While this is not strictly a technical solution, applying best data protection practices, and ensuring you are following PCI compliance rules, is a solid way to help secure your AWS containers.
For data protection, you should be looking at your local regulations, such as GDPR, and using them as a minimum baseline. In the case of GDPR, AWS already offers services that can process personal data in line with GDPR compliance, and AWS already has 500+ features and services that focus on security & compliance in a GDPR context.
These solutions aren’t automatically enabled, so you will need to ensure that you are encrypting personal data, providing easy ways to access personal data within a reasonable timeframe, and following best security practices. There are a number of advanced AWS services that can help you remain in compliance with GDPR, including:
- Amazon GuardDuty – a security service featuring intelligent threat detection and continuous monitoring
- Amazon Macie – a machine learning tool to assist discovery and securing of personal data stored in Amazon S3
- Amazon Inspector – an automated security assessment service to help keep applications in conformity with best security practices
- AWS Config Rules – a monitoring service that dynamically checks cloud resources for compliance with security rules
In terms of PCI compliance, the most important thing is to understand the flow of cardholder data within your environment. This flow will determine exactly how you need to handle and protect card data. That being said, there are certain universal steps you can take. For example, you should never hold full card numbers in your databases, at most you should save the last four digits.
Step 5: Understand General Host & Container Security Best Practices
Another essential step to securing your containers is following host and container security best practices. The first step is to remember that your host needs to be as secure as your container. There’s no point in building a robust container security system if a compromised host can instantly undo your good work. Securing your host will require you to regularly scan for vulnerabilities and monitor for real time threats.
It is also important to avoid using dependencies directly pulled from the internet, as you may be introducing security risks (unintentional or otherwise). The best practice is to build your own approved libraries that your applications can build from. You should treat these dependencies as if they were your own code: version them, scan them, and vet them.
Finally, you should also be using signatures to help track images to the person who signed them. This makes it more difficult to quietly substitute a signed image for a compromised one, and makes it easier for you to find out how it was substituted when conducting a review.
Step 6: Ensure your Logging & Monitoring Solutions Are Properly Configured
A robust monitoring configuration can help prevent bad things from happening, while logging can help you understand exactly what went wrong if something does slip under the radar. The first step you should take is to ensure that audit logs are enabled, and that you have a proper solution in place to monitor your containers for any potential problems.
The first step is to properly configure your container environment to communicate relevant security or log data to built-in AWS monitoring tools, like CloudWatch and CloudTrail. CloudWatch in particular enables you to set alarms that will alert you when key metrics suddenly increase, for example an unexpected spike in CPU usage.
Most users should also implement third-party monitoring tools that are able to find deep-dive insights into your logs, and flag more problems. One of the most popular tools for this is DataDog. This tool empowers users to determine performance metrics, and provides event monitoring for infrastructure cloud services. DataDog can be easily implemented into AWS and a variety of other cloud services.
Another commonly used tool, which is happily compatible with DataDog, is Prometheus. This is an open-source systems monitoring and alerting toolkit that’s been around since 2012. Prometheus is open source, and has significant developer and user support. AWS offers a managed service for Prometheus, making it simple to adopt any existing security systems into your AWS environment.
Securing Your Containers Is Only The First Step
Securing your AWS containers is one of the first steps you need to take on your AWS journey, but you shouldn’t stop there. You can reduce attack vectors, and improve the efficiency of your installation, by working with experts to spot problematic areas and take proactive steps to eliminate them before they can be exploited.
