Modern organizations follow multiple workload deployment patterns when it comes to adopting the public cloud. With microservices spread across on-premise and one or more public clouds, the communication between these microservices becomes more challenging. Few things which were never part of the consideration with microservices on-premise only, suddenly become much more important like firewalls, securing non-public apps on public cloud, etc.

In this blog series, I want to highlight architectural considerations for these types of use cases. The prime objective is to cover multiple scenarios as detailed below and define authentication and authorization mechanisms to add an additional layer of security for inter microservice communication:

1. On-Premise to public cloud API communication: This covers the basic scenario when a user on an organization’s VPN uses an API endpoint through a UI deployed on the public cloud. In the parlance of the diagram below it is User -> UI (SPA) -> API 1.
2. On-premise to on-premise API communication with intermediate service on public cloud: It is like a round trip from public cloud API to on-premise API before a user can see the details n UI. Referring to the diagram below it can be seen as User -> UI (SPA) -> API, it might look confusing as to why I am mentioning this as on-premise to on-premise communication where UI (SPA) is deployed on public cloud. I will make it clear in a subsequent blog.
3. Interaction between APIs deployed on two different subscriptions or accounts of the same public cloud platform: It is a very common pattern for B2B or B2C communication for enterprise services of an organization. API 3 accessing API 1 endpoint is an example from the diagram below.
4. Request journey from on-premise to Azure public cloud followed by service accessibility in GCP from within Azure: Here three clouds are at play: A microservice deployed on organization’s own data center invokes a rest endpoint on Azure public cloud and this Azure service has to call a service deployed on another cloud environment, GCP. This is not a very common use case but a simple analogy could be a user trying to generate a ServiceNow ticket via its own API deployed on a public cloud and this API calls ServiceNow’s API on their cloud. Again referring to the diagram below it is represented by User -> UI(SPA) -> API 2 -> API 4

Pictorially this can be represented as:

You might have already guessed that I am talking about all the interactions drawn in red above. As a disclaimer, I want to mention that when we talk about public cloud, the security perimeter has to be drawn at multiple levels such as tenant or subscription level policies, account firewalls, network (VPNs, Subnets), PaaS offerings, etc. Broadly speaking the security design considerations include authentication, authorization, transport security, Cross Site Request Forgery (CSRF), Cross Origin Resource Sharing (CORS), Cross Site Scripting(XSS), etc. My intention here is to describe the challenges and recommended approaches for implementing authentication and authorization at the application level.

Let’s dive deep into accomplishing our objective of securing On-Premise to public cloud API communication in the next blog.