7 November 2019
Service meshes have become a fixture in the cloud native computing landscape because they solve a key problem in microservices platforms/architectures : The need to manage interactions between microservices effectively.
By automatically controlling how services identify and talk to each other, a service mesh makes it possible for developers to build complex applications without worrying that they will be too difficult for IT teams to manage.
Yet while a service mesh can solve the microservices infrastructure management problem, there is another major challenge: Access enforcement.
It is critical to ensure control of who can access what also within the services, control access to business assets, functionality and data that are provided by the microservices within the service mesh. How is that achieved seamlessly within the service mesh? By deploying a sidecar enforcement service within the mesh. An enforcement solution that is secured, scales with your service mesh and reduces this burden from the service developer.
Access control for a service mesh should deliver six key features.
Access control in a complex microservices environment requires more than just the ability to permit or deny requests on a predetermined basis. Your decision engine must be able to enrich the “permit” decision with service specific instructions. For example:access to the <account> is approved, for view and trade.
It's not uncommon to have a dozen or more microservices in a single application. When you are managing access for that many services -- and when the services are updated constantly -- you need a smooth process for managing access policies and distributing them into the microservice.
If your service mesh fails, your application fails. That makes it critical to enforce access in ways that are not only inherently reliable, but that also minimize dependency on external services. And when external dependencies are required, they should be resilient to support the same level of service the mesh requires.
One of the major reasons why teams use microservices in the first place is to build applications that can scale up and down as demand changes. Your service mesh and the access controls that support it should be able to scale along with the application. Scalability should be considered in both access control components and the policies that feed it. You should be able to add new access policies easily as you introduce new microservices, or as you extend those you already have running. Without scalability, you undercut one of the key benefits of microservices.
The less exposure your access decision engine has to the network, the better. You should be able to enforce access as close as possible (from a network perspective) to the microservice that you're managing. Ideally, the enforcement decision should be done in the same Kubernetes pod as the microservice.
The microservice should be lean, focused and self efficient as possible. This drives a strong requirement of performance from any additional component in the service mesh, access control enforcement included.
The PlainID solution for the service mesh provides a secure, scalable, highly performing , and easy-to-deploy component for enforcing access controls within the service mesh. The component runs as a sidecar within the microservice pod, providing the best fit for the service mesh architecture.
The PlainID sidecar is part of the Policy Manager solution that provides advanced management capabilities for your access control policies, including full lifecycle support, version control, delegated management and more.
The product is designed to support basic and complex policies in addition to basic permit/deny, and more elaborated authorization decisions.
In all of these ways, PlainID makes access management for your service mesh as resilient, scalable and efficient as the service mesh itself, and ensures that you can take full advantage of microservices without compromising your ability to enforce complex access rules.
© All Rights Reserved 2021 PlainID