The security mechanisms in microservice architectures

With the introduction of a microservice architecture, the components responsible for authorization are moved to a separate microservice. There is a problem with providing trusted communication channels between services.

Introduction

Technical measures are aimed at improving the architecture of developed applications, improving the performance of specific application modules, improving the quality of source code, application scalability, and, of course, security.

From the point of view of improving the application architecture, developers distinguish the microservice approach as a way to separate the functional components of an application into separate services.

The issue of access control is a fundamental problem in the field of information security. This task includes such processes as granting access (authorization), suspending access, and revoking access. With the introduction of a microservice architecture, the components responsible for authorization are moved to a separate microservice.

Previously, when using monolithic architectures, the authorization process required passing the procedure for proving the legality of the user or data (authentication). With the introduction of the microservice architecture, the components responsible for authentication are also moved to a separate microservice. There is a problem with providing trusted communication channels between services.

Existing microservice security practices

• Mutual authentication (MTLS) . The implementation of mutual authentication mechanisms allows microservices to establish a trusted channel between each other based on the asymmetric cryptography of the Transport Layer Security (TLS) protocol. The article provides examples of two fundamentally different approaches to implementing mTLS projects: Docker Swarm and Netflix. In both cases, the main role is played by the Certificate Authority (CA), but the term for issuing self-signed certificates differs. In the first case, the reissue period is 3 months. In the second case, certificates are issued for both a long period and a short one (short-lived). Issuing short-lived certificates is associated with an attempt to solve the problem of revocation of certificates. mTLS solves the problem of communication channel encryption and authentication, but does not solve the problem of authorization.
• Security tokens (JWTs). The use of security tokens is similarly based on cryptographic principles. Tokens are created on the side of a separate microservice after successful completion of the authentication procedure. It is considered best practice to implement a token deactivation counter, which allows you to avoid its reuse in case of theft. The security token can be used multiple times to differentiate access between different microservices, as it contains information about authentication and authorization of a specific user. Among the popular standards, the most commonly used is the JSON Web Token (JWT) or OpenID.
• Fine — Grained Access control (Fine-Grained Authorization). You can manage access based on various policies. Two approaches are considered best practices: the group model of access control (Role Based Access Conrol, RBAC) or Attribute Based Access Control (ABAC). The first one is distinguished by the ability to manage large groups of users, while the second one is necessary for more fine-grained configuration. You can grant access to specific API methods using ABAC, and you can differentiate access to specific microservices by passing information about the user’s role in the JWT token.

Approaches to implementing authorization in a microservice architecture

NIST publication 800–162, dedicated to attribute-based access control (ABAC), provides a convenient terminology for describing interactions between components.

• Policy Administration Point (PAP) provides a user interface for creating, managing, testing, and debugging access control rules;
• The Policy Decision Point (PDP) determines access decisions by evaluating the access control policy that is being applied;
• The Policy Enforcement Point (PEP) applies policy decisions in response to a request from the subject requesting access to the protected object;
• The Policy Information Point (PIP) serves as a source of data needed to evaluate the policy, then provide the information needed by the PDP to make decisions.

When using a decentralized template, the responsibility for security falls on the shoulders of the development team of a particular service. The flexibility of configuring a specific microservice increases, but the task of correct interaction of the entire system becomes more complicated. Any change to the access control rules requires full testing of the entire functionality of the microservice, since access attributes and policies are located inside the source code of the microservice. Consequently, the speed of putting the microservice into operation decreases and testing costs increase. The decentralized template is shown in next Figure .

The convenience of using a centralized template with a single decision point lies in the ability to centrally manage access control rules that are detached from specific microservices. You can now test access control policies externally for anomalies in the test environment. The disadvantages of this pattern are the increasing network load on the rule distribution center, and caching is a possible solution. A centralized template with a single decision point is shown in next Figure.

A centralized template with a built-in decision point mechanism differs from a single one in that access decisions are stored inside the microservices themselves. This allows you to avoid having outdated data in the decision center cache from the previous model. The presence of outdated data on granting access may contradict the newly implemented access restriction policies. The template is shown in Figure 4.