In an upcoming National Institute of Standards and Technology (NIST) special publication I’ve co-authored with NIST’s Ramaswamy Chandramouli, we’ll be presenting recommendations around safely and securely offloading authentication and authorization from application code to a service mesh.
We’ll be discussing the advantages and disadvantages of that approach. This article presents an overview of the paper that will be presented later this month, at a one-day conference on service mesh security that Tetrate will host in partnership with NIST. The conference on Jan. 27 will cover a variety of topics around DevSecOps and Zero Trust Architecture in Multi-Cloud using Service Mesh.
A service mesh provides a framework for building a set of operational assurances for your organization. That framework includes
- an authenticatable runtime identity for services;
- the ability to authenticate application (user) credentials;
- encryption in transit of communication between services;
- a Policy Enforcement Point (PEP) separately deployable and controllable from the application — the service mesh’s sidecar proxies; and
- logs and metrics for monitoring policy enforcement.
Using these mesh features, you can build a set of controls for all applications that are part of the mesh (“all traffic is encrypted”; “all traffic to an application goes through the sidecar (PEP)”; etc). These controls provide a set of operational assurances for applications in your organization deployed in the service mesh.
Why Use a Service Mesh?
A big benefit of the service mesh architecture is that the key piece that allows you to build these controls — the sidecar proxy deployed next to every application — has quite a few security benefits over the traditional approach of building these operational assurances into your application code. Those benefits are:
- The lifecycle of the sidecar is independent of the application, therefore it’s easier to manage across your fleet. You can, for example, push updates and ensure you have a consistent version deployed everywhere.
- Modern implementations (like Istio) allow for dynamic configuration; it’s easy to update policies, and updates take effect immediately and without having to redeploy applications.
- The mesh’s centralized control allows for your security teams to build, manage and deploy policies that apply to the entire organization, so that application developers building business value are secure by default. They get it “out of the box” without having to do additional work.
A service mesh provides the ability to authenticate end-user credentials attached to the request — like a JWT. Many service meshes — Istio, for example — go further and provide the ability for the mesh’s sidecar to call external authentication and authorization systems on behalf of the application. This gives you the ability to move request-level policy enforcement out of the application code; instead trusting on the mesh’s assurance that requests that reach the service have been authenticated and authorized for the action the request is taking. The mesh can even be configured to pass proof of this to the application. This, coupled with the service mesh’s centralized control, means it’s possible for a central team to mandate and manage application-level security across the entire organization, delegating to individual application teams only to specify what permissions are required for each action in an application.
Finally, using the service mesh architecture, we can deploy our authentication and authorization systems as services in the mesh. Like any other service in the mesh, they benefit from the operational assurances the mesh provides: encryption in transit, identity, a PEP, authentication and authorization for end-user identity, and so on. This makes it cheaper to operate your organization’s authentication and authorization systems securely and reliably.
Registration is open for the virtual conference DevSecOps and Zero Trust Architecture in Multi-Cloud. Sessions will feature NIST scientists and IT leaders from the U.S. Air Force, Departments of Commerce (DoC) and Homeland Security (DHS), and the Food and Drug Administration (FDA), as well as cybersecurity experts and engineers from RSA, Flexport, the University of Maryland, and Tetrate.
This article was originally published by The New Stack.