From Bluemix I want to access an application in a customers data center using Secure Gateway service. I also want to give access to the destination (the customer application) to the Bluemix application only.
In the Secure Gateway dashboard under Advanced options of the gateway or the destination definition is a Network option where I can specify an IP address or address range plus port or port range. The help text says: "Set this destination to private to only allow access from specific IPs and ports." This is exactly what I am looking for.
But: How can I use this with a Bluemix app? I don't know the IP address of the Bluemix app. I am aware that I can figure it out but it is not static, the moment I stop and restart an app on Bluemix, the IP address may change. So this setting of the Network option would have to be done by some API call from the Bluemix application itself. Is this possible?
If not, why have this function at all?
The cloud application will use the "cap-sg-prd-<#>.integration.ibmcloud.com" hostname and the port they were given to connect into the cloud service. The client uses the destination configuration, which is downloaded to the client, to perform the backend, on-premises connection to their on-premises resource. So only their cloud application need to know about the cap-sg*/port number, all other connectivity is taken care by using the already established SecureGateway client connection.
In the form for the IP address you can also specify hostnames. You could try to provide the hostname of your Bluemix app. In my tests I did not succeed and had the entire connections cut off. Thus I cannot recommend trying to restrict connections right now.
By binding your Secure Gateway to the app or, even better, utilizing user-provided services to bind a database to an app you can leave the connection information internal to Bluemix. Here is a blog post with steps for user-provided services and on github is a demo for on-premise database integration utilizing the user-provided services and the Secure Gateway.
The hint regarding hostnames can be found in the Bluemix documentation for the Secure Gateway. The information about the Secure Gateway in the Knowledge Center is shy about it.
Related
I hope somebody can help to understand what I am doing wrong here because I am totally confused and lost.
I am trying to build an API Management in internal mode, and have in front of it a application gateway.
Following Microsoft Documentation I build the following resource:
API Management
Application Gateway
Virtual network
In the virtual network I set 2 subnets(application gateway and API Management)
2 Network Security groups one for each resources
As per the documentation and general advice I found online. I created a Keyvault and generated a certificate. In the Subject I set this CN:
api.test.com
I assigned a Managed identity to this KeyVault.
After this step I created a API Management Service. and the only api inside is a
/configurations
Once this was done. In the Newtork Tab I set the Api management to the internal mode and selected my virtual network and the subnet I designed for this service. So far everything went smooth. When the update completed I set the custom domain in the api management.
In the Tab Custom Domain I added a new domain, in the hostname I set the same CN I set in the KeyVault
api.test.com
and selected the KeyVault from which it has to fetch the right cert.
Everything is done here.
I created the Application gateway in the designed virtual network and subnet.
the first thing I set the backend pool to the gateway url of the API Management
api.test.com
I set a HTTP settings over protocol HTTPS port 443 as follow
Still in the application Gateway I set the Listeners on port 443 and selected my certificate from the KeyVault
In the Rules I configured the listeners and the back end targets to target the backend pool.
At this point, when I test the Probe:
I get the following error
Cannot connect to backend server. Check whether any NSG/UDR/Firewall is blocking access to the server. Check if application is running on correct port.
I checked both my security groups which are set as follow
this is the msg for the apim
and this for the application gateway
Can please anyone help understand what I am doing wrong here? Because I have no clue anyomore what could be the issue.
And please, if you need anymore info don't hesitate to let me know. And if is easy, I can post here my terraform script to deploy this infra.
You said: the first thing I set the backend pool to the gateway url of the API Management "api.test.com"
That url is inaccessible and points to a public IP (which I guess should be the app gateway IP)
The backend pool should be the private SLB IP address of the api management service. the listener should be listening to the host name so when it receives a request with that host name, it forwards it to the api management service through its private IP and a host header holding the same listener host name as a value.
So I have setup a web app, virtual network, application gateway using this link. I also added a virtual network gateway to the vnet so that I can integrate my web app to the vnet.
Now correct me if I am wrong but isn't the purpose of integrating your web app with virtual network to make it more secure? if so then I should only be able to access my web app through the application gateway public IP correct?
Currently when I hit the the myapp.azurewebsites.net, I get to the application.
Do I have to do something extra here?
You are mixing several different things here.
Application gateway is just a proxy (more or less). It has no control over whatever server it is routing traffic to. It cannot magically make it not accept traffic not from application gateway. That is for the server to decide (in your case you need to use web.config as far as I remember to restrict incoming IP addresses only to the IP addresses of the application gateway). So adding application gateway to the mix doesnt make it more or less secure.
Vnet integration works only one way, FROM the webapp inside the Vnet. Things inside the vnet cannot talk back to the webapp using "internal" vnet traffic, they have to use external IP address. So this wont really help you.
If you want your webapp to be available only inside the VNet your best bet is App Service Environment, but its a lot more expensive :(
Hello I've been searching everywhere and did not found a solution to my problem, which is how can I access my API through the gateway configured endpoint only, currently I can access to my api using localhost:9000, and localhost:8000 which is the Kong gateway port, that I secured and configured, but what's the point of using this gateway if the initial port is still accessible.
Thus I am wondering is there a way to disable the 9000 port and only access to my API with KONG.
Firewalls / security groups (in cloud), private (virtual) networks and multiple network adapters are usually used to differentiate public vs private network access. Cloud vendors (AWS, Azure, etc) and hosting infrastructures usually have such mechanisms built in, e.g. Kubernetes, Cloud Foundry etc.
In a productive environment Kong's external endpoint would run with public network access and all the service endpoints in a private network.
You are currently running everything locally on a single machine/network, so your best option is probably to use a firewall to restrict access by ports.
Additionally, it is possible to configure separate roles for multiple Kong nodes - one (or more) can be "control plane" nodes that only you can access, and that are used to set and review Kong's configuration, access metrics, etc.
One (or more) other Kong nodes can be "data plane" nodes that accept and route API proxy traffic - but that doesn't accept any Kong Admin API commands. See https://konghq.com/blog/separating-data-control-planes/ for more details.
Thanks for the answers they give a different perspectives, but since I have a scalla/play microservice, I added a special Playframework built-in http filter in my application.conf and then allowing only the Kong gateway, now when trying to access my application by localhost:9000 I get denied, and that's absolutely what I was looking for.
hope this answer gonna be helpful for future persons in this same situation.
I want to block some IP addresses from accessing my website, which is hosted over IBM Bluemix with Node.js runtime.
However, I don't know how I can block the list of IP addresses there. The only solution I came up with is not configure on Bluemix but write it on my Node.js app, such like:
function(req, res) {
req.ip // use this property to diverge, depending on the user's IP address
}
However, I would like to get it done on Bluemix part, not on my node.js app. Is it feasible to do it?
For your information, this was not feasible in Heroku, another PaaS. Maybe is it feasible in AWS, IaaS, right?
Blocking specific IP addresses is not possible as part of your described scenario. This is related to any PaaS as they are dealing with apps and services, not the network infrastructure itself.
There are slightly more options when operating on Bluemix Dedicated or Bluemix Local. The Secure Gateway service has options for blacklisting IP addresses, but that feature is used to secure your on-prem resources, not the app.
My Azure web role can, using remote desktop, connect with a browser (IE) to google.com and to a DMZ server on our corporate network.
My web role cannot connect via HTTP GET (IE) to a non-DMZ box behind the firewall. My web role cannot ping this box either. My service is hosted in north/central, allegedly all published IP ranges of north/central have been granted access to the target IP by our CorpIT people. They claim they are seeing no traffic via their sniffer from my compute instance IP when I attempt to ping or HTTP GET against the target local IP.
CorpIT wants help from the Microsoft side but we have no Microsoft relationship. I'm convinced this is the outcome of months of slapdash thirdhand firewall rules applied to the target environment in question. What can I do to further elucidate this for CorpIT?
thx in advance!
You can try to run a trace route or get a network trace from the Azure instance and see what you get back from where. You could also create a support case with microsoft:
https://support.microsoft.com/oas/default.aspx?&c1=501&gprid=14928&&st=1&wfxredirect=1&sd=gn
I wouldn't bet on using the IP ranges to make your applications work correctly. Windows Azure already provides you with some services that allow you to solve these types of issues:
Windows Azure Connect: Allows you to create an IPSec secured connection between your servers and your hosted services. This means you won't need to add rules to the firewall for incoming traffic.
Windows Azure Service Bus Relay: Allows you to expose WCF services to the cloud without having to add rules to the firewall for incoming traffic. Choosing this option might add some extra work for you to do, you might need to create a WCF service if you don't already have one and change the code in your Web Role to connect to this WCF Service.