Containers provide increased efficiency, portability, and scalability. Compared to virtual machines, they have a smaller footprint/attack surface and provide an additional layer of security by isolating applications. However, containerized environments are still susceptible to malicious attacks between containers or within the shared resources of the underlying host. Therefore, you need a strong AWS container security strategy that includes:
- 360-degree awareness of the container
- Full understanding of how it interacts with its environment
- Culmination of automated governance policies woven into the continuous integration/continuous delivery (CI/CD) pipeline
Container Security Pitfalls
Planning an AWS container security strategy can be trial-and-error, but security isn’t something you should chance — it requires knowledge and careful strategy. Gain a leg up on your container security journey by avoiding these six common missteps:
Starting with a customer-facing or mission-critical application
- Don’t take a chance on starting something that can negatively impact the customer, business processes, or revenue streams if you get it wrong.
- Do start with something that is safe to fail and offers leeway to get it right. Fail quickly, recover, and learn with minimal splash. For example, start with a small batch, back-end processing task instead of building an ecommerce site.
Focusing too much on the containers themselves
- Don’t make the mistake of thinking only about the containers when securing the ecosystem as the underlying container management hosts are equally important.
- Do assess the security of all components, regularly scan for vulnerabilities, and keep all parts of the system up to date while also monitoring for threats.
Ignoring automation as a table-stakes requirement
- Don’t ignore the minimum requirements or a broad ecosystem.
- Do leverage automation through every stage of the lifecycle to rapidly scale from dozens of containers to thousands. Build security, operations, introspection, and monitoring into it.
Assuming code libraries are safe
- Don’t blindly trust any third-party code. For example, plug-ins for SMS from sources that seem trustworthy can have unintentional or malicious code.
- Do maintain vigilance with governance, artifact repositories, and scanning libraries. Have approved libraries from which your applications can pull. Treat these dependencies as your own code. Version, scan, and vet them.
Giving containers unnecessary privileges
- Don’t allow liberal access to containers or assign rights to the containers themselves — this creates more opportunity for security risks. The more default access everything has, the more opportunity for a compromised container. It also makes it more difficult to track a breach’s entry point.
- Do wall off the containers and give out access only when critical.
Failing to properly vet an image
- Don’t assume that just because an image comes from an apparently trusted source that it can be trusted and is safe.
- Do perform tests on all images. Ensure you check the versions and history behind all components of your images.
Key Security Considerations
After avoiding the most common pitfalls, keep these four security considerations in mind:
#1: Registry
- Vulnerable source containers impact the entire platform, either by human error or through malicious changes.
- Mitigate the risk by maintaining tight access control and integrate with iIDP.
- Regularly scan, encrypt, and use HTTPs for transfers for images.
#2: Orchestration
- Insecure orchestration can lead to malicious changes and access to bad actors, resulting in rogue containers, such as cryptojacking containers.
- Mitigate the risk through tight access control, restricting public access.
- Ensure technology is updated regularly (don’t assume default security is in place).
- Monitor the configuration closely to make sure what is expected to run on containers and the host is what’s running.
- Have a system in place that can track what requests are being made. Is this the normal state? Or is there something malicious and running in this environment?
#3: Host
- Vulnerable system components create insecure configurations, resulting in lateral spread.
- Mitigate risk through tight access control.
- Monitor host and intra container traffic, and host behavior through logs and the network.
- Fortra’s Alert Logic offers visibility into not only who is talking to who but also what they’re talking about.
- If you’re in a modern architecture, the complexity of communications is impossible for a person to monitor on their own. You need to use tooling to scan throughout the entire stack and across the solutions.
#4: Container
- Application vulnerabilities resulting in a compromise result in overly permissive configurations.
- Mitigate risk by regularly scanning at run-time and monitoring systems and applications.
- Segregate containers and store sensitive data separately, putting them into essentially a vault and rotating them so it’s not the same key for a year or more. Rotate at regular intervals based on risk requirements.
- Developers don’t need to know the dbpassword, only where to get it when the application runs. Only the app, CISD platform, and possibly the host only need it.
Shared Responsibility Model
AWS provides security of the cloud, and the customer provides security in the cloud. Security is a shared, but not equal, responsibility. Some, but not all, of what is secured by AWS includes:
- System image library
- Perimeter security
- Storage
- Database
- Network
Some areas under your responsibility as the client include:
- Configuration scanning & management
- Log analysis
- Threat detection
- Access management
- Data encryption
- Incident response
Consider the way most platforms work, including AWS — it’s all based on API calls. In the end, it’s imperative to log and monitor those calls. Ensure critical functions like Cloud Trail are activated and stay on. For best results, rely on an automated system to turn them on if they’re ever inadvertently turned off (in a production environment they should always be on). It’s crucial to know who is talking to what, who requested it, when, and do they have permissions.
Platform Choices
How you run your own containers depends on what platform you use. Consider this:
Amazon EC2
- BYO ecosystem
- Run containers with your choice of orchestration
- Offers maximum flexibility and responsibility
- Works for hybrid workloads, migrating out of datacenter into AWS; minimal impact on existing processes.
- Can be an onerous but viable process
- You’re in control of everything from patching individual libraries to securing access controls on the network level
- Great if you have specific niche requirements
Amazon ECS/EKS
- Orchestration–aaS
- Run containers with server-level control
- Offers reduced complexity while retaining flexibility
- Easier integrations behind the scenes
- Enables you to focus on workloads and their success without worrying about controlling or tracking the patching of underlying hosts for running the orchestrator, while still maintaining the flexibility of the full platform
- Security is difficult, and if you’re not an expert or if it’s not your company’s focus, it can be a distraction, meaning you shouldn’t have to handle it all on your own
- ECS/EKS meets specific needs with minimal impact, allowing your team to gain maximum benefit without having to learn anything new, while offering a comfortable level of consistency
AWS Fargate
- Pure containers, run without managing servers
- For specific workload with minimum complexity
- Takes away the need to manage the underlying server
- Caveat: Because the host is abstracted from you, certain access, such as conducting bead security scanning on the underlying host, is unavailable, so it’s important to shift your mindset when using this
[Related Reading: AWS Fargate Security Best Practices]
Alert Logic & AWS — Delivering Peace of Mind
Alert Logic has been an AWS partner for more than a decade, AWS, offering Fortra’s Alert Logic MDR and Fortra XDR to deliver peace of mind from threats. Learn more about securing your AWS containers by connecting with Alert Logic.
Additional Resources:
Containers 101: What Is Container Security and How Does It Work?
The AWS Shared Responsibility Model Explained
How to Secure Containers on AWS
AWS Security Simplified: Support for the Shared Responsibility Model
Schedule an Alert Logic demo to see for yourself how we protect AWS workloads
