Microservices Management: Securing Endpoints

Microservices: You can hardly turn on the internet today without hearing about them or their BFF, containers. That’s because about every 10 years or so, applications experience a significant shift in architectural design. We’ve progressed from client-server to web to mobile and are now in the midst of the microservices movement. If you aren’t there yet, don’t fret, you will be. The majority of IT professionals – 86% to be exact – expect microservices to be the default within five years, according to the latest Lightstep Microservices Trends report.

Right on schedule.

With every major shift in application architectures has come changes in networking and security. Microservices is going to cause more changes, both because of their architecture and because they are most likely to be deployed using containers, which are like miniature clouds of chaos. That reality will cause some ulcers for networking and security pros who need to deliver and secure app endpoints.

One of the least-mentioned changes wrought by microservices and containers on applications is the very definition of "endpoint." We are accustomed to applications with a well-defined endpoint. One of the things microservices does is break that endpoint up into a hundred smaller endpoints, each which needs to be secured against attack and exploitation.

There’s a lot of surface area to cover. In fact, that’s one of the first things you should address as part of your efforts to secure endpoints: reducing the attack surface. You can do that by first making sure microservices aren’t on the public network. Get them off the internet, right now. I’ll wait.

Then, employ an API façade pattern to create a "virtual" app endpoint. This is the same concept used to scale applications using virtual servers. The API façade becomes the external official endpoint for the API and handles communication with the actual microservices. This virtual endpoint offers a strategic and convenient location to scan, scrub, and control requests and responses to and from microservices endpoints. API gateways, some ingress controllers, and application delivery controllers are some options for implementing an API façade.

Regardless of implementation, by forcing requests to traverse a virtual API you can better enforce Security Rule Zero: “Thou shalt not trust user input. Ever." That means every part of HTTP – from the URL to headers to the payload – should be treated as suspect when arriving at an endpoint. Using an API facade, you can scan for malicious or malformed content, enforce schemas, and employ additional protections like encryption of sensitive data that may be exchanged in the headers. An API façade at the ingress has the added benefit of shielding clients -- whether systems, humans, or things -- from rapidly changing APIs across the microservices that are ultimately called upon to process requests.

microservices mgt.jpg

Using a virtual endpoint also provides a strategic location in the architecture to add  additional security measures to defend against attacks, such as rate limiting and bot detection. Rate limiting at the API façade prevents microservices from being overwhelmed and potentially kicking off a series of cascading failures that bring the entire architecture down. Bot detection can prevent automated scanners from finding and exploiting vulnerabilities in the microservices platforms and services themselves.

And because those microservices are most likely going to be deployed within a containerized environment, be sure that developers and/or DevOps aren’t hardcoding secrets like credentials and keys in container images or environment variables. While not perfect, most container orchestration environments provide options for managing secrets securely. It’s a good idea to rotate keys on a regular basis.  

Finally, routinely check to ensure that container cluster consoles are locked down properly. It wasn’t that long ago that a Kubernetes console in the public cloud was left wide open -- accessible without a username or password -- and leaked access keys and secret tokens to the world. More disturbing was the discovery that intruders were using the environment and resources for their own personal Bitcoin mining operation. It isn’t just data attackers are after these days, it’s also resources. Keep those consoles locked down.

There are a variety of security issues with microservices that go beyond those associated with traditional applications. Some stem from the architecture itself, others from the reality that they’re often tightly coupled with still-maturing container environments. By employing an API façade pattern and encouraging and enforcing best practices for handling secrets in addition to securing consoles, you can dramatically reduce the attack surface and eliminate many of the most common security fails that wind up becoming breaches.