Identity, Microservices and Service Meshes

A lot of our customers are talking about microservices. Some are well on their way down the path, others are just getting started, and some are still wondering if microservices are really the best choice for them.

While we can’t tell each and every one of you what’s best, we at Ping Identity are heavily involved in microservices, so much so that microservices are the basis for our second generation platform, which underpins PingOne for Customers. One thing we have learned from our development is that controlling access to microservices requires a defensive, standards-based approach, one that ensures workload security and fulfills the tenets of Zero Trust in a reliable, scalable manner.

Microservice architectures are commonly defined by a loosely coupled set of small service components, which can be organized to provide an application or a higher-level service. These services should be as lightweight as possible and loosely coupled from one another, talking to each other via standard protocols such as HTTP REST or gRPC. 

The beauty of this simplification is that since services are small and modular, individual development teams can be responsible for all aspects of the service: design, development, deployment, scalability and monitoring. These services hide underlying details such as programming language or database type. Ideally these services are stateless, which makes dynamic scaling and load balancing much simpler; the client does not know or care which instance of a service it talks to from request to request. Another benefit of statelessness is that it allows new implementations of a service to be rolled out via “blue-green” or rolling deployment methodologies without introducing any downtime into the environment. 

While microservices may be simpler, building a secure and resilient environment for services that can organize and manage the deployment of anywhere from tens to thousands of services is not a trivial undertaking. This is why the vast majority of the organizations building microservices use Docker containers to package and distribute the services and Kubernetes to orchestrate the running of these containerized services. 

More recently, enterprises have been adding service meshes, such as Istio, to connect these services together and to provide much needed capabilities such as load balancing, monitoring and secure communications.

After all those considerations have been addressed, the next topic to come up is usually identity and access, which is where we at Ping start getting interested.

Microservices and Identity

So how can you best control access to microservices?

For many services, the answer often is OAuth and OpenID Connect tokens, typically produced by an Authentication Authority such as PingFederate. This works well for services that are called directly by API clients such as mobile applications, single-page apps or partner-hosted applications. PingAccess or an API Gateway can protect these services by rejecting requests from clients that do not have an OAuth access token and validating that the token was generated by a trusted authentication authority. They can also use access control policies to ensure that the access token has the correct scope to access the particular API method. If used, the OpenID Connect Identity token will provide the identity of the caller to the services for content personalization or additional authorization decisions. 

But what about the service(s) that service calls, or to put it another way, service-to-service authorization? 

We all hope that none of our services are ever compromised and that attackers never find and exploit a weakness in our environment. However, we also all know that we need to build a defensive strategy so that if one of our services is compromised, it cannot be used as a pivot by attackers to attack other critical services, a technique often referred to as lateral movement. We need to ensure that services have identities and roles, and that the identity and role are checked on every service-to-service call so that the caller is properly authorized. Workload security is a fundamental pillar of a Zero Trust architecture and we need to apply that to our service mesh.

Another factor to consider is how we communicate a user’s identity into the mesh from the outside and propagate it reliably from service to service if needed. How can we leverage that identity as an additional factor in deciding whether or not a particular service-to-service call is allowed? We need to protect against the case where a user or attacker has figured out a vulnerability or discovered a way to directly call a service that is meant to be called only by other services.

By combining the security capabilities of the service mesh with the standards-based identity and entitlement capabilities that Ping’s authentication authority provides, we can answer these questions and offer a consistent end-to-end security framework that provides identities, roles and enforcement for both users and services, while adhering to Zero Trust.

In part II of this blog, we’ll lay out the PingFederate and Istio configuration to achieve these goals.

We’ll explain a bit about how Istio creates and enforces service identities and roles, and talk about how users are authenticated via the Ping authentication authority. Then we’ll dive into how the user’s identity and entitlements can be enforced at the front door to the services via PingAccess and then communicated through the service mesh, where it can participate in further service authorization decisions. 

Stay tuned for this upcoming blog post, or subscribe to the Ping Identity blog to stay up to date with new content!