1. Challenges faced by microservices (why should we propose the security of microservices?)
- The attack surface becomes wider and the risk of attack becomes higher (how difficult will it be to manage 10, 15 or hundreds of independent microservices in a deployment? How can thousands of microservices be managed safely?)
- Multiple security checks may cause performance issues
- Trust between microservices gets complicated
- The distributed nature of microservices makes it difficult to share user sessions
- Multilingual architecture requires more security experts
2. Mainstream security mechanisms, some common technologies to protect microservice security
2.1 Border security
Enforcing perimeter security is a very traditional approach to securing microservices. This means that individual microservices are not secure; layers accessing microservices must be trusted. Access to the web application is secure, and the web application calls the microservice layer freely. Individual microservices interact freely with each other. There are some characteristics and requirements associated with microservices that make marginal security insufficient.
1. For various reasons, authentication or authorization should be performed per service.
2. Each fine-grained service is the responsibility of a small team. This may mean keeping the data secure is also their responsibility.
2.2 User authentication (username and password)
In the microservice architecture, a microservice application is composed of multiple independent microservice processes, and access to each microservice requires user authentication.
Microservice applications should follow the principle of single responsibility, that is, a microservice only handles a single business logic. The common logic of authentication and authorization should not be placed in the microservice implementation. Therefore, it is necessary to consider an abstract and common logic to perform identity authentication and authentication services for users. Since the API Gateway is used as the entrance to provide external services in the microservice architecture, it can be considered to provide unified user authentication at the API Gateway.
Specifically, Zuul+Spring Security+OAuth2/JWT is used for technical implementation.
In this approach, each microservice will be secured using BasicAuthentication. There are several ways to achieve this.
1. End User Credentials. In this case, each microservice requires the username and password of the end user to perform authentication or authorization. When an application calls a microservice or a microservice calls another microservice, it must pass the end user's username and password. This approach has many security risks.
2. Every microservice should have access to the end user credential store.
3. Username and password must be stored in memory or session by each service for use when one microservice is calling another microservice.
4. Trusted subsystem credentials. Usernames and passwords are used for trusted subsystems (for example, each entity in the system has a credential set). The disadvantage of this approach is that the end user is unknown, so authorization cannot be performed. What happens if an entity updates credentials? If the credentials are saved in a file, this file should be updated in each instance.
2.3 Two-way SSL
In this security mechanism, each entity in the system has a certificate (public and private) key pair and communicates with each other using two-way SSL. , In a normal SSL scenario, the server is authenticated by the client, but in two-way SSL, both parties authenticate each other. , which is a better approach than the end-user username and password approach because there is little risk.
However, some disadvantages of this approach are given below.
(1) Each microservice requires a certificate, so when updating a certificate, the update needs to be done in all instances.
(2) End users cannot be authorized or authenticated in this mode.
(3) It has similar advantages and disadvantages to the trusted subsystem pattern.
2.4 OAuth 2.0 OpenID Connect
OAuth 2.0 is an open source authorization protocol for applications to access each other's data, so OAuth is not an API or service, but an open standard for authentication and authorization (Authorization), and everyone has their own OAuth based on this standard.
Microservices can authenticate and authorize users using OAuth 2.0 as well as OpenID connections. There is an IdP provider that provides an OAuth 2.0 token to the requester. For example, the application gets an OAuth 2.0 access token, and this access token is used to call all services in the MSA. It can also be used for communication between microservices. With short-lived access, tokens simplify and improve overall system security. Using OpenID Connect, the identity of the end user can be retrieved, allowing the microservice to perform the authorization itself.
However, the disadvantage of this approach is the call to the IdP extra party.
(An identity provider (IdP) is a service that stores and verifies a user's identity. An IdP is usually a cloud-hosted service and is often paired with a single sign-on (SSO) provider to verify a user's identity.)
2.5 Self-Contained JWT Tokens
This is the most appropriate way to secure microservices.
A self-contained JWT token is one that has authorization information within the token itself, i.e. the token is signed by the issuer and all parties can verify the validity of the token.
This means that the microservice does not need to call an external party to validate the access token and obtain a JWT token. The additional call to validate the access token and obtain a bearer token is eliminated.
It has all the advantages of OAuth2.0, but without the disadvantages of short-lived tokens.
1. Problems with client control such as forced offline.
2. Security risks caused by Token being captured