I am developing a microservice which will run on AKS in production. I have to expose these service APIs through API management however challenge here is that API management is not available in same subscription. In that case, do i need to expose microservices publicly so API management can access it or vNet pairing between multiple subscriptions will help & microservice will be accessible in API management without exposing publicly.
You can add backend and APIM to different VNET and try to setup peering, that should work. Alternatively expose endpoints publicly, but with mutual certificate authentication.
VNET Peering and mutual certificate authentication are solutions as mentioned by Vitaliy.
Another possible solution is the APIM Self-Hosted Gateway. This is a new feature recently added to APIM. The new self-hosted gateway can be deployed to AKS cluster which might be a possible solution to your issue. This way you will need only to expose the APIM API endpoints.
https://learn.microsoft.com/en-us/azure/api-management/self-hosted-gateway-overview
https://learn.microsoft.com/en-us/azure/api-management/how-to-deploy-self-hosted-gateway-kubernetes
Related
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.
We have integrated API Management with Service Fabric in Azure as outlined in this document. Everything is up and running, but we would like to ensure that the traffic between API Management and Service Fabric Stateless Service (ASP.NET Core) is encrypted using HTTPS. Currently the API Management logs show that the traffic is HTTP.
Is there a way to enable HTTPS (or at least encrypted) traffic between API Management and Service Fabric?
APIM gets those http endpoint from SF itself by calling IServiceResolutionClient.ResolveServicePartitionAsync. Are you sure your stateless service is configured with HTTPS scheme at Service Fabric end?
I have a bunch of rest services. I want to have a kong api gateway implemented at the front. I dont want to go into kong admin api and manually add all the exposed api.
Can i take help of any service discovery implementation like eureka or consul to autoconfigure my apis to Kong.
I'm afraid not.
Kong's configurations are stored in postgres and updated through the admin API, you can write your own program to import.
I'm setting up an environment with an API Gateway (KONG) and microservices (Spring-boot apps), but I have a lot of doubts/concerns with the SSL communication between them.
Should I put the SSL settings in the API Gateway or on the microservices?
Currently my microservice app has its own SSL certificate and it runs in a container through 8443 port.
But now implementing the API Gateway, I'm not sure if I have to remove it from my microservice and setting up in the API Gateway or add it in both.
I expect the correct communication between my microservice and the API Gateway in order to the clients are able to consume the services through 8443/ssl.
Your API gateway will be facing the clients. So for secure communication, your API gateway must be behind the SSL.
Regarding microservice, it's up to you to have it behind SSL or not. Both way it will work. According to me, if your microservices are restricted within the VPC (and API gateway is part of the same VPC) and not exposed publicly, then there is no need to have microservices as well behind SSL.
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.