I have a project with microservice architecture (on Docker and Kubernetes), and 2 main apps are written in Python using AIOHTTP and Django (also there are and Ingress proxy, static files server, a couple more made with NginX). I'd like to split these Python apps into separate smaller microservices, but to accomplish this probably I also should move authentication in a separate app. But how can I do this?
Probably I should also add that I'm asking not about specific authentication methods like OAuth, JWT, etc, but about dependencies and responsibilities splitting inside cluster architecture.
To my mind, a nice solution would be some plugin to Ingress NginX proxy server, or a microservice before it, so that my Python authenticating proxy won't care about methods destination, like some middleware, just read headers/cookies, check access token or sessionId, then set userId if the access is valid, and pass the request further.
A brief and simplified architecture is presented below:
And here is what I imagine, mention fewer complicated connections:
But I'm not sure if this is reasonable. In addition, such approach would reduce advantages of K8s Ingress, which provides amazing interface for updating path table from the bash, but, as far as I know, doesn't allow to run any request handler before it, so I'll have to run custom NginX proxy without nice K8s integration.
Thus, what are other possible architectural solutions?
I could only imagine creation of a single request handler, that performs all the authorisation and passes requests to other microservices (or by RPC), which don't care about authentication, but I don't think this is a generally perfect solution.
Well, I found a lot of info after digging on the Internet and one and a half of consultations. There is an architectural pattern named API Gateway, which describes an entry point in a cluster, and this is just what Kubernetes Ingress does, and what I imagined in my question. In a general case, it is proxy server, which is the only entry point to the cluster microservices, and it may perform caching, DDoS protection, it may support different API protocols, manipulate URIs, manage API throttling, monetisation, and perform the authentication I need. Therefore, there is no authentication during microservices communication inside the cluster, because all the required arguments, identifiers will be presented in the requests.
In Kubernetes, NginX Ingress is quite popular, it also supports Basic Auth and OAuth2, which is not a perfect solution, but at least something. There are alternative Ingress solutions for Kubernetes: Kong, Ambassador, Traefik, which provide much more features (though Kong is based on NginX too).
In the world of Java and Spring the Spring Cloud Gateway exists to solve such problems, which, just like K8s Ingress, allows to describe path tables with YAML, yet it is extendable, allows to easily embed your custom code for any authentication method.
Besides, most of cloud platforms provide their own API gateway services with more or less features, including Google Cloud, Red Hat, AWS, Yandex Cloud. However, it seems they lack authentication methods just like opportunity to be extended, though they aren't much relevant in this question.
You can find more about API Gateway pattern and it's implementations here:
cloud.spring.io: Spring Cloud Gateway
1: https://cloud.google.com/api-gateway/docs
2: https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do
3: https://aws.amazon.com/ru/api-gateway/
4: https://cloud.yandex.ru/services/api-gateway
5: https://microservices.io/patterns/apigateway.html
6: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/
7: https://learnk8s.io/kubernetes-ingress-api-gateway
8: https://cloud.spring.io/spring-cloud-gateway/reference/html/
With microservices, JWT are preferred way of authentication & authorization. You can use cloud resources like GCP IAM or OKTA. OR you can run Keycloak in your cluster as a microservice.
Also token is normally valid for fixed amount of time. So frontend app should refresh the token periodically.