I've deployed an application on aws using kops and ingress nginx controller.
From what I’ve understood it looks like ingress controller allows to expose each services deployed in the cluster publicly. So it makes me wonder about security and authentication.
What is the architecture of my project ?
I got 3 services deployed in a cluster:
-client-ui (front-end)
-authentication-api (creates/generates/verifies JWT token and call other services like data-api)
-data-api (an API that create/read/update/delete sensitive data in the DB)
So the question is: if Ingress controller exposes all services, how do you restrict access to specific service, if the user is not allowed to ?
In this case data-api should only be accessible from authentication-api. So if in my browser I type
www.client-ui.com/data/getXXX obviously I should not be be able to access that endpoint. I should only be able to do it from authentication-api if his jwt token has been verified.
So I guess some apis should be accessible only from within the cluster and some publicly !?
Could you please explain how can I do that ?
Thanks
Depending on the cloud provider, there are different annotations on the ingress services for that. What you want is an internal load balancer for a specific ingress resource.
In your case (AWS) this should be:
annotations:
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
See:
https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/
https://github.com/kubernetes/ingress-nginx/blob/c3ce6b892e5f1cc1066f81c19482dded2901ad45/docs/user-guide/multiple-ingress.md
Related
Is it possible to use spring cloud oauth 2 server with kubernetes api gateway ingress.
I have used it with zuul to authenticate user before making a call. Can I do similar with ingress?
Edit 1:
To explain it more clearly, what I am trying to achieve
I am using token based oAuth2 implementation given by the spring cloud.
oauth is running as one of the service behind the zuul.
zuul has routes mapped for the oauth server and resource server
client call the auth server via zuul and gets the token.
client call resource server via zuul with token passed
zuul is configured to validate the token before making a call to resource server.
In this way we can stop any downstream traffic to go without a valid token.
can we do token validation in ingress with auth server running with in a cluster?
I have not used Spring Cloud OAuth 2 but as OAuth is a standard I believe you can set it up if you are using Nginx Ingress as the ingress controller, you can specify and external Oauth Provider (As OAuth generally has the same flow) like this on your ingress:
...
metadata:
name: application
annotations:
nginx.ingress.kubernetes.io/auth-url: "https://$host/oauth2/auth"
nginx.ingress.kubernetes.io/auth-signin: "https://$host/oauth2/start?rd=$escaped_request_uri"
...
You can find more information here with an example of using GitHub as an OAuth provider
There are currently three different nginx-ingress-controllers (see here), which differ in functionality. I believe that none of these ingress controllers themselves can perform an oauth token introspection. However, requests can be routed to the authorization server's introspection interface using the auth_request module.
Specifically for your case, you can use the auth-url annotation (see) in the ingress controller to direct the requests to the introspection interface of the spring cloud oauth2 server (see). The introspection interface is available under /oaut/check_token by default when #EnableAuthorizationServer is used. If the introspection interface returns a 2XX, the ingress will forward the request. This functionality is based on the auth_request module, which expects a 2xx response code from the external service if the access is allowed and 401 or 403 if denied.
If you use JWTs and want to validate the request by only checking the signature, this can in some cases actually be done by the ingress itself. To my knowledge, only the nginx plus ingress controller (paid) can validate JWTs. But there is also the nginx-based kong-ingress controller, which you can equip with pulgins (see here). There is e.g. promoted with oauth2 integration and JWT validation.
Did you find out more than me?
I recently have learnt and practicing Microservice using Spring technology. I am currently writing a small program that has Eureka Server, Configuration Server, Gateway and Account service. I have all of my services register its instance to Eureka and have my Gateway gets its configuration from Configuration Server. After that, I got some question, should I my Account Service fetch its configuration directly from Configuration Server, or from Gateway because it can be done in both way. I think, if I decide to fetch it through Gateway, it might be better because Gateway is a load balancer, so in case if there are multiple Configuration Servers out there, I don't need to worry if any of them failed or down as Gateway can handle this for me. But, doing so, isn't I put too much weight on Gateway because it need to handle this and another requests. Furthermore, I am not sure and I can't find any information about if there is a way to load balancing Gateway or is it makes sense to do so?
Please advice and explain. Thank you.
Only user's requests from UI need to be passed via Gateway. Services should be able to fetch their configuration during startup disregarding whether gateway is online or doesn't exist at all.
Also I'd advise you to avoid registering config service in Discovery (Eureka). I suppose there is no need for your users to send requests to config service.
Along with spring cloud config and gateway documentation I'd recommend you to get familiar with these 2 books:
https://www.manning.com/books/enterprise-java-microservices
https://www.manning.com/books/spring-microservices-in-action
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.
So I have a very small micro service architecture built using Eureka service discovery. The problem I am facing right now is that I only want my service endpoints to accept request from my api gateway, as it is right now you can just make a request straight to the service and hit that service endpoint. Is this a problem Kubernetes would solve? Or Is there a more practical way of doing this?
You should be using network policies to control the traffic between the services.
In kubernetes the services you want to expose internally use service type ClusterIP. This is default anyway which means services are accessible within cluster only. your api gateway is exposed as load balancer service type which then takes traffic from external world and talks to services internally. Depending on your cloud provider you can use firewall in front of load balancer since you can compromise security by simply exposing load balancer. e.g. azure kubernetes you could use application gateway. You can also replace the api gateway with ingress controller. it's very powerful reverse proxy controller which you can expose directly to traffic and that would talk to your services internally.
You really need to understand concepts so i would recommend following links
https://kubernetes.io/docs/concepts/services-networking/service/
https://blog.getambassador.io/kubernetes-ingress-nodeport-load-balancers-and-ingress-controllers-6e29f1c44f2d
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