I am using the Azure Application Gateway Ingress Controller with AKS, it quite okay to me with url routing, TLS, web application firewall. But it looks like the AGIC doesn't support Authentication (I'd just need to have basic authentication)
Is there a way to have the Authentication features enabled (just with Azure stuff)? Or I have to implement the Authentication at api level (every single micro service)?
In fact, I might need a gateway that I can offload more functionalities like authentication, logging, monitoring
Regards
Related
I have implemented microservices architecture in Spring Boot. All services are accessible from the front-end. There are 2 types of API in few Microservices -
Public - (Directly Accessible from the front-end)
Internal - (for inter-service communication)
I have implemented JWT based authentication. But I want to know how to implement auth for internal APIs?
In internal API we will not get the JWT token. Auth is needed because someone can mock a private API.
For Authentication, we are using an auth service. All other services call the Auth service before every API call to authenticate the request.
Auth is needed because someone can mock a private API
While this may be true, an attacker would need to be inside your network already.
However, assuming you still need secure intra-service communication, you could look at service discovery to mediate this communication. Service registry platforms such as Eureka or Consul, will allow you to set up service discovery.
Eureka is commonly used in sprint boot applications, and is fairly lightweight, but weighted toward AWS hosting.
In addition to other benefits, such as configuration management, failure detection, and load balancing, these platforms will also enable you to secure your intra-service communication.
I implemented a Spring backend which is responsible to store different data (users, lectures, ...). This backend is secured with a JWT and everything is working fine. For my studies I want to enhance the backend and now I want to use a microservice architecture instead of a monolith. For this purpose I have the requirements to use Docker and Kubernetes. I always read articles which write that I need a Authorization Server and a Ressource Server when I want to use the JWT in a microservice architecture. Is that correct? And do I need a Gateway (e.g. Zuul) for my purpose? Can someone help me to structure the project and give advice for the technology stack. At the end the whole project will run in one single server.
I implemented a molotithical backend, secured with JWT.
Kubernetes officially supports authentication to API server within JSON Web Tokens(JWT) through OpenID Connect tool using OAuth 2.0 protocol for user request identification. However, this only represents a part of Authorization model, which determines how authenticated user can be granted with appropriate security policies or roles to manage Kubernetes cluster resources.
In order to build or migrate application to Kubernetes, you might consider to expose application outside the cluster, for that purpose Ingress proxies requests to exact service by matching request path. Actually, Ingress is a logical resource element which describes a set of rules for traffic management via Ingress Controller. Therefore, Ingress controller can play a role of API Gateway by delivering L7 network facilities like: load balancing, SSL termination and HTTP/HTTPS traffic routing for nested application services.
As you mentioned Zuul gateway can be one of the option for the edge proxying service in front of Kubernetes cluster, however I would recommend to look for some more Kubernetes oriented solutions. Istio is a good example, as it brings a wide set of network router functions with a quite simple integration into Kubernetes cluster via its core Service mesh design. Istio provides end user authentication via JWT within declared authentication policy.
Alternativelly, you can get through Nginx plus features with announced JWT authentication as well.
I'm wondering what to do with an API Endpoint when using a API Gateway. For example when you following the tutorial here: https://wiredcraft.com/blog/securing-components-in-a-microservice-context
You are using keycloak and kong (api-gateway) to secure the api. With kong you're getting an new Endpoint under http://localhost:8000/data. But the "original" express Server is still listening on http://localhost:3001/data.
That means that when a user/attacker knows the url of the "orignal" service and doesn't use the kong url (port 8000) he/she can still work with the api.
So my question is about the strategy and what to do with the original api? How could that be secured. Shall we implement the keycloak request on the api as well? But where are the benefits of kong then?
Your API gateway gives you a single entrypoint that simplifies how client applications access your services. You could add keycloak security on the gateway and not on the services behind - perhaps if you've a setup where you can block network access for clients to any services except the gateway. But even then you might still want the gateway and keycloak on the services behind.
The reason you might put keycloak on the services behind is because they are likely to need to know the identity of the user making the request. If they are going to read the token anyway then it might be most straightforward to add keycloak to them. And you'd still want the gateway to simplify life for clients. You'd then also want the gateway to forward the token to the services behind the gateway. (We're using keycloak and spring cloud gateway on the Activiti Cloud project and this is essentially how we decided to secure the services themselves with keycloak and have the gateway forward the token to them.)
i have created two java spring-boot micro services they are
1) producer
2) consumer
and i have used spring eureka server for service registration and discovery . it worked fine . then what is the use of Netflix Zuul.
Let's suppose you have 20 services to which user can interact to, and of course we are not going to expose each and every services publicly because that will be madness (because all services will have different ports and context), so the best approach will be to use an API gateway which will act as single entry point access to our application (developed in micro service pattern) and that is where Zuul comes into picture. Zuul act as a reverse proxy to all your micro-services running behind it and is capable of following
Authentication
Dynamic Routing
Service Migration
Load Shedding
Security
Static Response handling
Active/Active traffic management
You can go through documentation here
If you have enough experience in the domain, you could look at zuul as an API gateway like Apigee. It is very feature rich and touches up on a lot of different concerns like routing, monitoring and most importantly, security. And eureka as a service discovery platform that allows you to load balance (in Linux terms the nginx or haproxy) and fail over between your service instances.
Typically the backend services that perform the server side business operations (i.e. core) are not exposed publicly due to many reasons. They are shielded by some Gateway layer that also serves as reverse-proxy. Netflix Zuul serves as this gateway layer which easily gives you the capabilities as mentioned by #Apollo and here
Suppose there are 2 backend services:
A product service (to get the product info),
An inventory service (to get the available quantity).
Additionally to that, there is a frontend web application to display product details.
All the examples I see on the internet are about the frontend and the API gateway being the same application and using Zuul just as a reverse proxy.
My understanding is API gateway should be a separate application (layer) and frontend application should use it to call backend services.
In that case what is the benefits of Zuul? why not just use feign to create a client for both services and provide an endpoint for the frontend application ?
Feign client and Zuul are two entirely different components in Spring Cloud Netflix.
Feign Client is a glorified REST Template with additions such as Retry, Fallbacks etc. You can think along the lines of Apache HttpClient
Zuul on the other hand is a proxy / reverse - proxy / gateway. Typically Gateway should be a common entry point to your backend services. It should be a separate layer which allows you to add common functionalities like Authentication, Auditing, Logging etc. As #ootero mentioned, you can easily add Filters in Zuul to achieve this functionality.
Zuul as a Proxy server not only route requests but Zuul filters could also be used for handling crosscutting concerns like:
geolocation
token decryption
authentication
request / response manipulation
Traffic shaping
You mention Feign clients and that would work (to the best of my knowledge) with Java-based front-end apps, what if the front-end app is developed with Angular or React?