I am looking for a suitable API gateway for my project. I have looked at traefik with authelia and envoy but they don't fit 100 percent. Does anyone know of any other tools you can recommend to me?
Requirements:
sticky session
ldap authentication
JWT
not Java
no cloud solution
compatible with a Service Registry (e.g. Consul)
support Websockets/gRPC
compatible with prometheus would be nice
Related
I am working on a distributed application project where there is need for rate limiting and authentication depending on the client consuming the service on an api gateway. I am wondering the best solution for designing the gateway.
Should I go with Spring cloud gateway or Spring Cloud function/AWS Lambda to create the gateway service?
I'd argue that using AWS API Gateway will make your life easier...
The benefits of using AWS API Gateway are:
it will remove all the operational cost of maintaining, configuring, monitoring and operating a Spring Cloud Gateway instance,
it will be highly available, with failover,
it will give you instant features like rate limiting, api keys, caching, authorization, canary testing, proxying, integration mapping, environments
it is very very cheap ($3.50 x MM requests).
The benefits of using Spring Cloud Function:
Define your API's as code within the application code itself
Leverage the ecosystem integration within Spring, for example, to run it locally on a dev's PC.
Cons of using API Gateway:
Deployment of new API's will be harder than using Spring Cloud Gateway (you need to configure each new resource/method)
Your costs are now tied to the number of requests... if you have a 900.000.000 millons/months API it could get expensive
Vendor lock-in
Cons of using Spring Cloud Function:
Operative cost of maintenance
Single point of failure
You can use Amazon API Gateway.
For more info on request throttling and quotas, please refer to the docs:
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
I will rather use Istio gateway Envoy proxy rather than both options if permitted. Keeping my operational and maintenance cost little and no code change.
I have a spring boot application which runs on Azure Kubernetes Service and it exposes a private IP, using this IP I have configured this API on Azure API Manager. All the traffic will be coming to this spring boot application via API manager. Client to APIM connection is secured with SSL certificate coming from azure API manager. But from API manager to back end API application is not secured it is plain http. Is there any security issues for this architecture?
For your situation, since you already use SSL certificate to protect your APIM, I think the architecture is no problem even though there isn't any security configuration between APIM and backend api. APIM will not expose your backend, so others can't get your backend IP or backend url according to the APIM. So I think you do not need to add any other security configuration for your architecture.
For the comment about Azure AD mentioned by Tiny, you can also use Azure AD to protect your api or APIM, but I think it is unnecessary.
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 a spring boot app deployed to Swisscom App Cloud that should to be secured with mTLS.
Obviously there's spring security... Specific to Swisscom App Cloud I read about securing traffic on https://docs.developer.swisscom.com/adminguide/securing-traffic.html.
It is unclear to me how the two play together...
If I enable mTLS via spring security, would that work as is or would I need additional configuration for the Swisscom App Cloud? (I came across HTTP routing which mentions passing client certificates for mTLS https://docs.developer.swisscom.com/concepts/http-routing.html)
Is the configuration of mTLS on Swisscom App Cloud a replacement for what I would otherwise enable with spring security or would I still need to configure something within my application?
Securing traffic mentions deployment manifest and BOSH manifest, is the latter (and maybe additional) configuration needed to enable mTLS on Swisscom App Cloud (i.e. would I need to have access to configs besides the deployment manifest) ?
Update
My use case that I have a REST API that will be consumed by a client outside of Swisscom App Cloud. It was decided that it shall be secured using mTLS.
The admin guide you're referring to is meant for platform operators (i.e. Swisscom), so it's not a resource that can be leveraged by end users.
What is your use case? If it's only a security requirement to check off a list, be aware that the platform itself will be using mTLS internally soon, so the whole path up until the app container is secured. That might be enough for your auditor.
If you really need to validate client certificates by yourself, CF's way of doing so is leveraging X-Forwarded-Client-Cert (https://docs.cloudfoundry.org/concepts/http-routing.html#-forward-client-certificate-to-applications).
However, we've currently not enabled this (there was no need for it up until now), but we can do so.
Update:
According to this explanation, insertion of X-Forwarded-Client-Cert is actually done transparently by the platform. So if you add the client application's certificate to the server application's truststore, it will verify the client certificate.
Update 2:
As you can see in the discussions below, it looks like there is currently conceptually no easy way to allow apps to do proper mTLS using X-Forwarded-Client-Cert. The only option currently is using tcp routes, which is something you can request with your Appcloud support team.