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?
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.
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
I was learning micro service concepts in spring cloud and its service discovery mechanism. What I understand is all service providers register themselves in service discovery. Consumers get endpoint details for required service from discovery server and then connect to the endpoint. It's all works fine when consumer is a component built on spring cloud.
When we need to consume a service from Mobile client like react native, what should be the approach? Are we supposed to use a static endpoint which receives all requests from mobile and invoke actual endpoint using inputs from service discovery server?
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.
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