Rethinking Application Security With Microservices Architectures

Microservices architectures and container-based deployments are all the rage among application developers today. Microservices functionally break down larger applications into smaller, discrete services, and containers are viewed as a natural compute platform for microservices architectures.

Each service can be represented by multiple containers in a microservices cluster. Each service is purpose-built to provide a set of functions, and services interact to make up the entire application. It isn’t unusual for a mid- to large application to have between ten to twenty services. The net effect of all this decomposition is that the physical characteristics of these applications are dramatically different from their multi-tier cousins. Microservices application architectures require a rethinking of security assumptions and practices. Understanding the common attributes of container-based, microservices applications is a necessary step to securing them.

Here are 9 key concepts and best practices you’ll need to understand.

Concept 1: “Endpoint” Proliferation

The functional decomposition of traditional applications results in a significant number of microservices instances. From a networking standpoint, each service instance is still a unique network endpoint. While the attack surface for the application is no longer concentrated in a few isolated servers, it increases simply due to the spread of services. A lot more ports are now open, more APIs are exposed, and authentication just became a distributed issue as well.

Concept 2: Ephemeral IPs and Indefinable Perimeters

Containers can be spun up or down anywhere in matter of seconds and the traditional notion of the perimeter is fading away. Moreover, with dynamic addressing and scaling of services, it is no longer feasible to statically configure IP addresses or steer traffic to traditional perimeter security appliances. Many network constructs to isolate applications, including zoning and VLAN setups, are restrictive or not viable for many implementations.

Concept 3: Entropy and Container Masquerading

The very advantages offered by the container model go against assumptions made by traditional security mechanisms. Containers increase the entropy of the underlying compute infrastructure because they can be dynamically orchestrated across services or even across multiple clouds. Another challenge is that a container’s IP address may be invisible outside the host where it is run. For example, the default mode of a Docker container uses masquerading or natting, making Docker containers on a host invisible to the outside world. In these cases, configuring security in an external appliance becomes impossible since the traffic sources cannot be identified.

Concept 4: Service Discovery and East-West Chattiness

Microservices and container environments have empowered developers with the ease and power to deploy new services as well as service instances dynamically, but it complicates security policy definition since administrators don’t know which services exist or the rules governing their interactions. In addition, the proliferation of services inside the data center or cloud means that more transactions require inter-service interactions to be fulfilled. Depending on the application, a seemingly simple North-South request can translate into hundreds of East-West transactions to fulfill.

Concept 5: CICD Practices

DevOps principles and continuous delivery goals are promising concepts for lines of business but they also mean more frequent builds that production teams have to deploy and each application iteration can mean potential security issues. Organizational processes and tooling for security are still evolving to match development agility.

Gain insight into the latest threats and emerging best practices for managing them. Attend the Security Track at Interop Las Vegas, May 2-6. Register now!

 Security Best Practices for Microservices

Security will clearly play an important part in the decision to adopt and deploy microservices applications for production use. According to the research note, 2016 Software Defined Infrastructure Outlook by 451 Research, nearly 45% of enterprises have either already implemented or plan to roll out container-based applications over the next 12 months. As DevOps practices gain a foothold in enterprises and container applications become more prevalent, security administrators need to arm themselves with the know-how to secure applications. Start with these four best practices for securing microservices applications:

Best Practice 1: Discover and monitor inter-service communications

Security administrators often do not know the permitted interactions between the different services in a microservices application. Yet, when applications need to be secured, administrators need to configure security policies that govern the interactions based on an application deployment guide or other less formal instructions from developers. Rules can also change as applications evolve and new services are brought online.

One way to mitigate this challenge is to observe or visualize inter-service traffic as a way to establish the baseline for policies by understanding application behavior. Service discovery enables automatic identification of new services to others entities in the application. Use these capabilities to arm both developers and administrators with information about real-time service interactions and performance. It will also help security teams notice anomalous communication patterns or even identify potential breaches.

Best Practice 2: Segment and isolate applications and services

Micro-segmentation is policy-governed walling of applications through granular security enforcement. Micro-segmentation can be relatively coarse-grained, for example, to isolate the production environment from the development environment, or more granular, for example, to govern interactions between the catalog service and the order management service in an e-commerce application. For segmentation to work in microservices applications, enforce policies at the cluster level on every host running service instances, since traffic steering to perimeter-based enforcement points is not practical.

Best Practice 3: Encrypt data in transit and at rest

Encrypt traffic between applications or services that make up an application to meet compliance requirements and to improve security especially when the traffic crosses public networks. Keep certificates up-to-date, manage software versions, and fix known SSL issues. Invest in tools that can help manage and distribute keys, and keep them up-to-date while also addressing the issues of resource-scaling so that encryption doesn’t affect performance.

Best Practice 4: Automate policy management and configuration

Complex administrative functions across disparate systems and repetitive tasks can often lead to human error. The single most avoidable, yet common source of security incidents, continues to be human error due to misconfigurations, or missed updates. Automating tasks such as defining policies that can be replicated across applications, separating administrative vs. development roles, and managing SSL certificates and keys, can go a long way towards reduce these errors. Likewise, automating the deployment, management, and maintenance of the entire stack will go a long way towards improving the overall security posture in dynamic environments.

Related Content: