Why we need an RPC Security Standard

Protection from software supply chain attacks, VPC penetration attacks and malicious insider attacks is critical to secure cloud infrastructure. One part is to ensure such an attack never takes place, but the other part of it is to ensure that even if such an attack takes place, the attacker is severely limited in what they can do.

Microservices within an organization’s cloud infrastructure today often trust each other fully. To access APIs from third-parties, these microservices may hold and utilize powerful API keys that give them unrestricted access to the tenants at other SaaS services belonging to the same organization. As a result, a compromise of the cloud VPC can lead to a severe compromise of an organization’s cloud services, even if those services span multiple cloud platforms or utilize multiple SaaS services.

Since these cloud services often hold personally identifiable information (PII), a compromise of an organization’s cloud services is also a serious compromise of the organization’s privacy policies, and exposes their users to serious harm.

Even when there is no compromise, there is an added privacy vulnerability: In an environment where user identity cannot be transparently passed through in a call graph, each component ends up having to process user identities just to pass it to the next service. This is unnecessary access to user identity information, and can end up in logs and database entries where it should not be.

Attack Scenarios

The following attack scenarios in an organization’s multi-cloud environment are considered in proposing this standard:

• An attacker compromises one of many microservices. If that microservice has API keys to other APIs, then the attacker gains access to those keys too.
• An attacker spins up a new service that acts as a “Microservice-in-the-middle” between two genuine services
• An attacker spins up a new service that originates spurious actions

Here, an attacker may gain capability to perform the above attacks as a result of many possibilities - such as compromising the software supply-chain, compromising privileged access to penetrate the cloud infrastructure, or by being a malicious insider.

A Potential Approach

In current systems, there is no way to guarantee that an action taken by a service on behalf of a principal is related to any request performed by the same principal to the service.

In order to limit an attacker’s reach post breach, it is important that microservices do not completely or fully trust each other. Microservices must be able to limit the actions they perform upon request by another microservice in terms of the scope of the data it enables an action to read or affect.

Furthermore, microservices in the call graph of an action that do not need to know about a user’s identity should transparently propagate the principal information without learning about the user on behalf of which the actions are being performed. This will enhance privacy because fewer logs retain user information and fewer services will be required to have the right to obtain user information.

If instead, a microservice services requests based on the principal on whose behalf an action is initiated, and the authorization scope of the request, then the damage that could be done as a result of a breach can be limited. In such a system, a compromised service may impersonate any principal that has performed a request to the service, but not any other principal.

In the proposed system, the identity of the principal initiating the action, and the authorization scope of the original request initiated by the principal can be securely verified by the receiving microservice.

Since such communication between microservices can span multiple cloud platforms, and can span APIs or services provided by different organizations, a way to limit trust between microservices based on open standards is required.

SGNL looks forward to working with others in the industry in proposing and standardizing a solution to secure RPCs uniformly across microservices, multi-cloud environments and third-party APIs.

Related Work

• One standard related to the above proposal is SPIFFE. SPIFFE enables secure communication between microservices, but does not limit trust between microservices.
• Service meshes such as Istio: Istio provides secure communication between microservices, including an integration with SPIRE, a SPIFFE implementation. In addition Istio provides “request level authentication”, which verifies a request token (a credential attached to a request). It can verify the credential and reject requests with invalid or missing credentials. Istio can also match JWT attributes (e.g. “iss”) to values defined in the configuration file. Istio has a request authentication feature, which is implemented using “custom authentication”, which means that Istio does not itself provide any trust mechanisms for request authentication, but provides the hooks for other trust mechanisms (such as Firebase Authentication) to interoperate with it.
• Policy orchestration / enforcement initiatives such as OPA, Hexa and others provide frameworks through which policies may be distributed and / or enforced in cloud services, but they do not provide secure means of identifying the principal originating the action or the original authorization scope of the action.