I was looking a lot about the capability for Istio to have programmable routes at the ingress controller as a solid replacement for Kong API Gateway plugins. A simple example would be to have a rule in the Istio Virtual Service that rejects API calls when the user has a license expired in the application that is behind.
That means, the Ingress Controller to be capable enough to query something inside the app to determine the license status, and based on that response, block/allow traffic that is coming from a particular customer (which are being identified by a header)
This is something I do with Kong plugins, but I didn´t find anything similar on Istio.
The simplest solution to rejecting requests of a user is to attach that information in the authentication process (to the cookie or the jwt token), and then use Virtual Services to reject requests with those.
Another solution (more complex) would be to use Envoy Filters with Lua scripting, in which you can add custom logic and decide if you want to proceed with the request or not.
Related
Recently, I am learning Java's microservice framework, and I don't understand some of the concepts.
In what form is the exposed service exposed? For example, the mall system includes order service and payment service. In what form are these services exposed? Is it the form of the previous http request? If it is an http request, should these services include the controller layer in the MVC three-tier architecture.
What is the difference between the gateway and the controller in springmvc. It feels that they all distribute the received requests to the service. Does that mean that the controller is no longer needed with the gateway?
These questions have been bothering me for a day,I need your help.
I found some posts, they are all talking about the function of the gateway, but few people mentioned the difference between the gateway and the controller.
I even feel like nginx + controller is the same as the gateway
I am using Yarp to reverse Proxy into internal apps. The authentication is handled by another service and I want to challenge certain request by using api keys assertion. Having gone through the documentation and the sample project here,I have trouble implementing it. I went the route of middleware but it is applying to all sets of routes and I do not need that.
Looking into using Istio to handle Authorization for an application built on a microservices architecture in Kubernetes.
One thing we're looking to accomplish is to decouple the authorization of a service by utilizing Istio Authorization.
Our API Gateway (Kong) will handle the verification/parsing of the JWT tokens and pass along any required attributes (usernames, groups, roles etc) as headers e.g. x-username: homer#somewhere.com (abstracts that from the services)
What we want to accomplish is along with verifying based on roles etc we also want to ensure that the x-username is also the owner of the resource e.g. if they are accessing:
/user/{userID}/resource
That would mean if userId matches the value of the x-username header we can continue serving the request, otherwise we'll send a 401 etc
Is there a way to configure this as part of Istio Authorization?
Thanks in advance for your time
What you're looking for is attribute based access control (abac). Look into authorization engines e.g. Axiomatics that plug straight into Kong and provides that level of access control (ownership check).
Kong authorization handler on GitHub
Technical webcast on the integration
You could also choose to call Axiomatics from Isitio using an adapter based on Istio's authorization template.
Policies in Axiomatics are written using either XACML or ALFA which are the 2 OASIS standards for ABAC / fine-grained authorization.
You could easily write a condition along the lines of:
rule checkOwner{
deny
condition not(owner==user.uid)
}
BTW you probably want to send back a 403 rather than 401. The latter refers to failed authentication.
Question
Can I get nginx to call another microservice inside of AKS k8s prior to it routing to the requested api? - the goal being to speed up requests (fewer hops) and simplify build and deployment (fewer services).
Explanation
In our currently deployed Azure AKS (Kubernetes) cluster, we have an additional service I was hoping to replace with nginx. It's a routing microservice that calls out to a identity API prior to doing the routing.
The reason is a common one I'd imagine, we recieve some kind of authentication token via some pre-defined header(s) (the standard Authorization header, or sometimes some bespoke ones used for debug tokens, and impersonation), we call from the routing API into the identity API with those pre-defined headers and get a user identity object in return.
We then pass on this basic user identity object into the microservices so they have quick and easy access to the user and roles.
A brief explanation would be:
Nginx receives a request, off-loads SSL and route to the requested service.
Routing API takes the authorization headers and makes a call to the Identity API.
Identity API validations the authorization information and returns either an authorization error (when auth fails), or a serialized user identity object.
Router API either returns there and then, for failure, or routes to the requested microservice (by cracking the request path), and attaches the user identity object as a header.
Requested microservice can then turn that user identity object into a Claims Principal in the case of .NET Core for example.
There are obviously options for merging the Router.API and the UserIdentity.API, but keeping the separation of concerns seems like a better move. I'd just to remove the Route.API, in-order to maintain that separation, but get nginx to do that work for me.
ProxyKit (https://github.com/damianh/ProxyKit) could be a good alternative to nginx - it allows you to easily add custom logic to certain requests (for example I lookup API keys based on a tenant in URL) and you can cache the responses using CacheCow (see a recipe in ProxyKit source)
I would like to have some guidance regarding how to handle authentication for my restful service to be able to support a couple of different scenarios, see included image?
I've been thinking about this problem for a couple of week without finding a solution for all of the cases and even if I'll make trade offs I'll be running into problems
If we skip the Mobile application and the use of Curl, there's no need to expose the service to the public and it would be possible to use basic authentication for the server to server communication. But we'll still need to put some responsibility at the "Web site for ninjas only" to pass the (openid authenticated user) as part for the http header?
In this case we're using Google apps to manage credentials for our co-workers and I don't like the idea to manage another username/password within the service if it's possible to avoid.
Is there any sustainable solution for my dreams, so that I can build awesome features for the client and implement a tight api that manages the authorization for different resources for a specific user?
Another possible to solution might be to integrate the service with the openid provider, but then I'll have problem with passing the user from "Web site for ninjas only"