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.
Related
Upon reading Azure documentation I still cannot figure out if we can design routing for our Express Route in the way described below.
We are planning to use one proxy server(with one public ip) for all O365 traffic. ( dedicated only for O365 ). Obviously, some of the O365 traffic can and should use ER, but some need to use internet (CDN, DNS, etc).
The goal is to announce proxy server ip toward ER as a /32 and toward internet as /22.
My concern is "assymetric routing" . Can this type of routing create the problem when Microsoft will send traffic to our proxy server via the ER while egress path from our AS lies via internet ?
PS. I am aware that some of the traffic should not be "proxied" or undergo DPI. Thats a security requirement.
You should not have any trouble with the configuration. Given that you are using 2 different address spaces/ CIDRs of Public IP's Provided by your ISP.
The /32 public IP will be advertised to Azure Microsoft Peering over the express route via BGP. Azure, on the other hand, Azure would advertise the Public IP's of the services that you are using. Which can be controlled via Route Filters. Note: The ASN and Public IP needs to be validated for the NAT.
Coming to the Asymmetric aspect that you are concerned about. The o365 services will not propagate the routes to other non-O365 services such as Storage/CDN/DNS.
That said, whatever is coming from the 22 CIDR will be serviced by the non-O355 service and will go over the internet.
The fear for asymmetry occurs when you are consuming the O365 services over the internet instead of consuming them over the express route. Then, there are chances of asymmetry.
Instance 1:
CIDR /22 advertised to Azure over express route and you accidentally consume the O-365 services over the internet. Since, within the O365 cloud the route is populated to use the express route, the return traffic from Azure will come over the ExR circuit. This would be labeled as asymmetric route.
I hope I have clarified your doubt about the architecture. Let me know if you have any further questions as you proceed with this configuration.
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 :(
In the world of microservices endpoints should not (must not) be hardcoded. One of the best ways to do this is to have a DNS and let each microservice register while starting. By doing this whenever microservice A wants to communicate with microservice B it just asks DNS for endpoints where B currently listens.
What I do not understand is: How microservices know where the DNS lives?
Basically DNS is just a 'special' service and I can have one or multiple instances of it right? So I should not hardcode it's endpoint too or should I? And let's say I do - what if DNS instnace is moved to different location? Do I have to manually change it's location in configuration?
Does anyone happen to know how to design this? (or can anyone just point me to any document where this is explained since although there are many information about microservices and dns I can not find this particular information anywhere - maybe it's just too trivial and I am the only one who does not get it)
Manual setup of DNS is possible, as stated by the other answers, but I would recommend to use an infrastructure that supports the service discovery in all respects. For example kubernetes has built in DNS support and makes it very easy to expose a service that can consist of any number of Pods.
An infrastructure technology like kubernetes will also make many other respects of the microservices architectural style easier to implement, including high availability and scalability.
Please see the official docs for some more information.
DHCP solves this problem. When a host boots it sends a broadcast DHCP message. The DHCP server responds with many values, one of which is the location of DNS servers.
In the case of micro services, the host OS (or container host) will be configured for DNS via DHCP. The microservice code uses the OS DNS functions to resolve addresses.
https://en.m.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
You can use your local network to discover services, via Dhcp and whatnot. But that requires that all services are already "registered" within that DNS server.
Microservices can find each other via service discovery, server or client side. If you choose client side service discovery, you can use tools like Consul, which provides a bunch of great features. One of which is a DNS endpoint which allows queries via SRV records with <serviceName>.consul.service domain names.
Consul has it's own DNS endpoint, you can configure your services to use that (usually on port 8600 locally, as Consul agents run locally).
But you can also configure an actual DNS server to forward questions to Consul, so that you can easily mix service discovery drive by Consul with manually setup services within a Bind instance or similar...
Known hostname solution. The fixed part would be the service domain name, for instance xservice.com. You can query this host using standard DNS tools (e.g., dig in your shell, etc).
Finally, in the DNS bound to xservice.com you then add a SRV record with further details.
A SRV record lists all the service details, including:
the symbolic service name;
the canonical hostname of the machine providing the service;
the TCP (or UDP) port on which the service is available.
There are many other info as well. Please see Wikipedia for the complete list.
Please keep in mind this is a somewhat static solution. If you are looking for a more dynamic one, then Oswin answer might be a better fit :-)
We've got an API micro-services infrastructure hosted on Azure VMs. Each VM will host several APIs which are separate sites running on Kestrel. All external traffic comes in through an RP (running on IIS).
We have some API's that are designed to accept external requests and some that are internal APIs only.
The internal APIs are hosted on scalesets with each scaleset VM being a replica that hosts all of the internal APIs. There is an internal load balancer(ILB)/vip in front of the scaleset. The root issue is that we have internal APIs that call other internal APIs that are hosted on the same scaleset. Ideally these calls would go to the VIP (using internal DNS) and the VIP would route to one of the machines in the scaleset. But it looks like Azure doesn't allow this...per the documentation:
You cannot access the ILB VIP from the same Virtual Machines that are being load-balanced
So how do people set this up with micro-services? I can see three ways, none of which are ideal:
Separate out the APIs to different scalesets. Not ideal as the
services are very lightweight and I don't want to triple my Azure VM
expenses.
Convert the internal LB to an external LB (add a public
IP address). Then put that LB in it's own network security
group/subnet to only allow calls from our Azure IP range. I would
expect more latency here and exposing the endpoints externally in
any way creates more attack surface area as well as more
configuration complexity.
Set up the VM to loopback if it needs a call to the ILB...meaning any requests originating from a VM will be
handled by the same VM. This defeats the purpose of micro-services
behind a VIP. An internal micro-service may be down on the same
machine for some reason and available on another...thats' the reason
we set up health probes on the ILB for each service separately. If
it just goes back to the same machine, you lose resiliency.
Any pointers on how others have approached this would be appreciated.
Thanks!
I think your problem is related to service discovery.
Load balancers are not designed for that obviously. You should consider dedicated softwares such as Eureka (which can work outside of AWS).
Service discovery makes your microservices call directly each others after being discovered.
Also take a look at client-side load balancing tools such as Ribbon.
#Cdelmas answer is awesome on Service Discovery. Please allow me to add my thoughts:
For services such as yours, you can also look into Netflix's ZUUL proxy for Server and Client side load balancing. You could even Use Histrix on top of Eureka for latency and Fault tolerance. Netflix is way ahead of the game on this.
You may also look into Consul.io product for your cause if you want to use GO language. It has a scriptable configuration for better managing your services, allows advanced security configurations and usage of non-rest endpoints. Eureka also does these but requires you add a configuration Server (Netflix Archaius, Apache Zookeeper, Spring Cloud Config), coded security and support accesses using ZUUL/Sidecar.
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.