I am deploying RESTful API's in Azure and protecting them with teh Azure API Manager. However, I've not been able to figure out how to restrict calls to the actual API to block requests going around the API manager. Is there a way in the web.config or something to restrict IP's, domain names.... on teh .net web api?
You can whitelist the IPs in c# code. Check below link for code changes,
https://weblogs.asp.net/senthil/restrict-ip-address-in-asp-net-web-api
You can get the static IP address of APIM in overview section. But you have to consider below points,
In all tiers of API Management, the public IP address (VIP) of the API Management tenant is static for the lifetime of the tenant, with some exceptions. The IP address changes in these circumstances:
The service is deleted and then re-created.
The service subscription is suspended or warned (for example, for
nonpayment) and then reinstated.
You add or remove Azure Virtual Network (you can use Virtual Network
only at the Developer and Premium tier).
For multi-region deployments, the regional address changes if the region is vacated and then reinstated (you can use multi-region deployment only at the Premium tier).
Premium tier tenants that are configured for multi-region deployment are assigned one public IP address per region.
You can get your IP address (or addresses, in a multi-region deployment) on the tenant page in the Azure portal.
Yes, you can configure call limits and quota policies through the API Management Portal, including inbound and outbound policies. Below is the policy template, you can choose what you want. Here Restrict caller IPs would meet your requirements.
For detailed configuration, please check this article and follow the steps.
Related
So I am trying to make Google cloud's API gateway serve requests from a private IP based backend. Currently, the backend is a Kubernetes based service. However, I couldn't find it explicitly being mentioned whether its possible or not.
Has anyone else encountered such an issue given that its a pretty common use case? It seems possible only when the API gateway infrastructure has a link to the VPC network(route table) or an explicit private connection.
After looking for a while I think that the best way to do what you are asking is to use Private service connect, this allows private consumption of services across VPC networks that belong to different groups, teams, projects, or organizations and also lets you connect to service producers using endpoints with internal IP addresses in your VPC network.
Here is a guide of how to use Private Service Connect to access Google APIs.
the Google API gateways exist only for serverless product and is intended to be use only against serverless backends(s). It is possible to configure it against public IP’s that are hosted on our Google backends because they leverage the same x-google-backend configuration key-value pairs in the openapi.yaml for API Gateway, but more niche features like authorization on behalf of backend services, or limiting access to backed services hosted on non-serverless platforms like GKE are currently not supported. a possible workaround could be to set up endpoints directly with your GKE cluster you, this documentation could help you first, second, third
Best regards.
Cloud Run is providing a domain *.run.app to access the service deployed. I am wondering how Google Cloud Run handling requests from one to another Cloud Run service. Is all the service to service communication internal even we have a custom domain instead of *.run.app?
The definition of "internal" is not clear.
Your request stay in the Google Network. Is it internal or external?
To resolve the Custom Domain, a DNS resolution request (port 53) is performed on the public network, but the content of the request stays in the Google Network and forwarded after the resolution. Is it internal or external?
So, as long as you use Google Services (in premium network option), you don't go out of the Google Network and thus you can consider this as highly secured.
I assume, my answer isn't very clear, in fact all depend if you trust or not the Google Cloud network.
We have following structure for my application. currently we have used Any for both source and destination (on port 3389) while defining NSG rule for our Service Fabric to allow calls from mobile app. But our security team has raised concerns on Any-Any rule. Is there any way to optimize this?
Note: our mobile app is public and anyone can download from app store.
Any to Any rule open SF for attach really so you should limit the IP from your traffic manager given your current model.
Azure API management already have build in support for Service Fabric so my suggestion is to remove the traffic manager between then API management and SF. Then you can do is to limit the traffic to SF only from the API management which is much easier.
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-api-management-overview
Authentication requirement you can delegate that to the API management ie validate JWT token
I was creating a Traffic Manager profile with end points for Dev and QA slots for Web Apps and wondered that is it not possible?
How can I create Traffic Manager endpoints for Dev and QA slots as we do it for production?
Same way. Just select App Service Slot.
You can also use Powershell to enable TM for any external endpoint if portal interface does not allow you to do something you need.
Azure Traffic Manager External Endpoints and Weighted Round Robin via PowerShell
I have a public Bluemix CF APP which exposes a REST Service. I would like to have the option, that the public url bound to the CFApp would be inaccessible from outside. The REST Service itself should only be usable from other CF Apps in my org, for example over API Management. I don't want to implement an own security mechanism for it, because API Management provides already everything I need to control, which clients will access my service. So some kind of private route inside Bluemix public, only available to runtimes and services in my Bluemix organisation.
This is not currently possible with IBM Bluemix, due to limitations in Cloud Foundry.
All bound routes are accessible from the external network.
If you want to have a private API exposed, you have the following options.
Add authentication to the REST API, managing the credentials as a user-provided service bound to all the apps. The API will be accessible externally but only by users with the credentials.
Use an application service, like a message queue, to expose an internal RPC-style API. Applications can bind to the same service and it will only be accessible internally.