Defining the Perimeter in a Microservices World
Security was simple back when applications were confined to a single server. All it took was a firewall that acted like a box where everything in the box was secured and safe, while anything outside the box was vulnerable. The firewall was where the buck stopped, and it formed the perimeter for your network and your application.
Alas, times have changed. New technologies have turned perimeter-based security on its head, and it’s time to rethink what security means for modern, cloud-native applications.
How the Cloud Changes Security
The biggest impact the cloud has on security is in the way firewalls work. Firewalls operate on allowing or denying access to users based on IP address. The user can be a person, such as an employee, or another application. The biggest change in this aspect is that the cloud providers like Amazon Web Services (AWS) have now taken access control into their own hands. They have mature tools for identity and access management (IAM) that are deeply integrated into their own cloud platforms. For example, AWS IAM can control access to an application running on EC2 instances by allowing the app to fetch data from an S3 storage bucket, or send API calls to AWS CloudTrail for logging. It can also define role-based access control (RBAC) to give permission for only authorized users to view or make changes to the application’s code. In this sense, AWS IAM (without using the term firewall), performs much of the duties of a firewall.
Additionally, cloud vendors have put in place the shared security model where they are responsible for the security of the cloud and customers are responsible for security in the cloud. They take care of security at the most basic level and put in place strong defaults to avoid malware attacks. Additionally, tools like AWS Inspector and AWS Macie automatically scan all resources in the cloud to check for vulnerabilities. While cloud vendors do their part to maintain safety and security, security is most often compromised by a customer’s failure to secure their own resources in the cloud, such as by storing secrets without encryption, leaving an S3 open endpoint or being careless about how they sync data to the cloud.
The cloud is an improvement in that it takes on some key security responsibilities. But it also brings a different approach to security which takes some getting used to.
Containers and Microservices Can Be a Security Nightmare
Coming from the simple days of peripheral firewalls, the cloud made security more nuanced for IT teams. However, with the advent of containers, this equation reached a new level of complexity.
When they started out, the mantra around containers was that “containers do not contain.” Linux security professionals were vocal about the weak process isolation between containers, and that a vulnerability couldn’t be easily contained from spreading to neighboring containers, as multiple containers share the same guest OS.
Then there was the introduction of microservices architecture, where a single monolithic application is decomposed into multiple interdependent services. While the “divide and conquer” approach was attractive for operational efficiency, one look under the hood at the networking that connected microservices with each other would make any security professional cringe. Services need to communicate with each other in a many-to-many network — now called a service mesh. Though they’re so closely connected, there needs to be a way to ensure latencies, failed instances, and security threats are contained to each service so that even if one service is taken down, the others perform their function until the affected service is reinstated. Needless to say, the number of requests and complex routing patterns all seem like a heavy tax to pay for a utopian approach to infrastructure. That would have been true if not for novel approaches to security, and particularly network security, for modern cloud-native applications.
New Approaches to Microservice Security
Today’s containerized applications redefine what the perimeter means. It takes a multi-pronged effort to adequately secure cloud-native applications. Let’s discuss the key strategies.
Container-specific security: Container images are the key source of vulnerabilities, as publicly shared images are frequently infected and are unsafe for production environments. Image scanning features of container registries make it easy to scan all container images downloaded. They run checks for the common known vulnerabilities and follow the CIS Docker Security Benchmark.
Importantly, when running containers, they need to be run as unprivileged, non-root containers. This prevents vulnerabilities from spreading to other containers and the host. Additionally, steps need to be taken to keep container images as small as possible. This reduces the potential surface area for an attack. Additionally, ensuring container lifespans are short (and not more than a week) can keep your system more dynamic and less prone to vulnerabilities.
Policy-based network security: Container networking is now a complex service mesh that can’t be configured manually. Instead, you need a set of policies that automatically enable communication between authorized services on an as-needed basis. Tools like Weave, Linkerd and Project Calico employ this approach and are gaining widespread adoption among early adopters of container orchestration. This has a bearing on firewalls. Rather than having a peripheral firewall that if breached leaves the entire system vulnerable, you now have micro-firewalls that protect each service. So, even if one of the services is breached, the others remain secure.
Threat detection: The number of container security and monitoring solutions available is many, and each caters to one piece of the whole security puzzle. What brings them all together and provides holistic security is a threat detection tool that can provide end-to-end monitoring. Importantly, during the course of an attack, it identifies suspicious patterns and quickly highlights the origin and extent of the attack. This requires advanced data analysis using machine learning but hides the complexity under the covers while allowing security teams to take advantage of advanced security measures without the need for a dedicated data science team.
Centralized logs: In the container era, logs have taken on an even more prominent role in SecOps. With the large number of containers, numerous network requests, and constantly changing states, logs help monitor all the events in detail. They are essential during troubleshooting. Logs need to be stored centrally and made easily accessible via a dedicated log analysis tool. Powerful open source solutions like Elasticsearch make it easy to get started with log analysis for containers.
As infrastructure changes and attacks become more complex, security solutions need to keep pace and evolve with the times. The cloud took on some of the roles of the traditional firewall by managing access control internally. This further changed with containers and microservices, making peripheral firewalls obsolete. However, from the ashes of the traditional firewall, new approaches to application security have risen.
Container-specific security for container images, policy-based security for networks, threat detection at runtime, and centralized log analysis are the new way to secure microservice applications. There is no looking back to the good old days of simple security. While the security perimeter has been blurred in a microservices world, the new micro-perimeters are capable of providing a level of security that was not possible before. This promise is worth all the complexity it brings.
Twistlock sponsored this post.
Feature image via Pixabay.