Making sense of the network layer

The first layer of security in microservices is the network layer. Every microservice needs a URL and an IP address, through which it communicates with other components. Restricting the scope of the microservices’ IP address will limit connectivity, which can radically improve security. Two easy address limiting methods are private IP addressing and address translation control.

Most virtualization tools — including container management software, like Docker, and private cloud software, like OpenStack — and most public cloud services will deploy applications within a private IP subnetwork. Private IP addresses are visible only on private networks, which means microservices that have private addresses can’t be accessed from the outside. If these components need access to the outside, you can translate the private address to a public IP address. The size of a private IP domain will depend on the range of applications that use the microservice, but private addresses are available to support millions of components. Even though private addresses are invisible to the outside world, they can see each other. For microservices used within a single application or a limited group of applications, this technique can add considerable security.

Address translation control takes advantage of the fact that users and applications are typically represented by a URL that has to be translated to an address. This translation usually occurs via a DNS server, but other resource registration tools, like service-oriented architecture’s UDDI (Universal Description, Discovery and Integration) or an API broker, can also be used. You may need specialized tools to support policy control over access to microservice addresses, which can make address translation control more complicated to apply because it won’t protect against intrusions that already know the microservice IP address and access that address directly. However, it will work with microservices that have public IP addresses.

Microservices that need addresses across multiple applications make address-based security more complicated. For a different approach, you can group applications that share microservices into a common cluster, based on a common private IP address. Through this approach, all the components within the cluster are capable of addressing each other, but you will still need to expose them for communications outside that private network. If a microservice is broadly used across many applications, you should host it in its own cluster, and its address should be exposed to the enterprise virtual private network or the internet, depending on its scope.

Figuring out access control

Network-based security reduces the chances of an intruder accessing a microservice API, but it won’t protect against intrusions launched from within the private network. A Trojan or other hacked application could still gain access at the network level, so you may need to add another another level of security in microservices. This is the access control level.

Access control relies on the microservice recognizing that a request is from an authentic source. One way to support access control is with an API broker or manager. The broker provides an authentic user with the address of a microservice, providing an identity token as well. That token can then be passed to the microservice, which can authenticate it and the user who’s obtained it. It’s also possible to use encryption on the message links to microservices, making access to them dependent on having the proper encryption key.

Access control is more difficult for shared microservices, and the more they are shared, the more difficult it becomes. It’s important to ensure that every valid use of a microservice is covered, and if one use is removed from a composed application, it has to be decertified. Access control is also harder to apply if different users of the same application have different access rights with respect to components and/or data. It’s difficult in this case because certification will normally verify companion components, not the users of the application. Broader user- or role-based authentication requires the entire workflow to remain user-aware, and it requires that user identity be established firmly and passed on through the API broker.

To help limit the scope of microservices and ease the deployment of both network and access control security, you can replicate a microservice within specific applications or groups, rather than use it as a shared service. While this can reduce the value of microservices, it can also simplify their design and scale by controlling the number of possible parallel users.

Logging is last up

The final layer of security in microservices is logging, which should be the final layer for all forms of security. Audit trails don’t prevent an intrusion directly, but teams can use them proactively to analyze use patterns and reactively to track invalid users.

Microservices use logs will quickly detect all of the valid access patterns, including the source of requests, as well as the time and dates. This information will help auditors or automated analytics processes spot atypical use patterns. If use deviates from a pattern, you always have the option to shut down the requests until the problem is traced and fixed.

Using security layers can present complex interdependencies, and complexity isn’t exactly a user goal. In order to better manage your complex microservices security environment, Istio — based on open middleware — is an emerging management platform. Istio offers an open platform model to control microservices security, networking and load balancing. Istio may not be quite ready for large-scale deployments, but it’s a tool that teams should explore now and consider for adoption when tests prove its effectiveness at scale. While building a layered security approach is the most reliable option right now, Istio and future microservices management tools will likely help give you an even better handle on your multidimensional microservices security strategy.