I'm currently considering Heroku as a new hosting platform. So far I've been working with various services on Amazon AWS so I'm still trying to figure out some pieces, especially when it comes to security.
I'm used to setting up a firewall & restricting the access. E.g. should only the application have access to the database as well as certain IP ranges. In Heroku there is no such setup possible, I can't configure a firewall.
With Heroku Private Spaces, I can whitelist IP addresses for my apps but that's not really satisfying.
Is it not necessary with a PaaS to configure a firewall to make sure the DB is not externally accessible for example? Additionally, my test and staging environment shouldn't be publicly accessible either (for security reasons).
I would appreciate your thoughts on this.
Related
I am struggling to have a simple service acting as a reverse proxy in Azure.
I need it because the API that I want to communicate with uses IP whitelisting. That's why I want to set up a reverse proxy service with a static IP. My application (whose IP is cannot be static) would communicate with the target API via the reverse proxy.
With some research I found the following options:
Creating a Web App with some custom IIS config - I'm not sure if that's still valid, because the guides I found are pretty old
API Management - that seems pretty heavy and I've heard it's not going to be easy to configure
Application Gateway - that requires a VNet, which I do not even need.
Azure Function with Proxy - I think that option is no longer available with Functions V4. What's more, I would have to also set up NAT Gateway to have a single outbound IP. That seems overly complicated.
Creating a custom Web App with code that does the proxy logic
All these options seem to be too complicated for a simple task that I need. Basically, I want to have public reverse proxy, when I hit https://my-reverse-proxy.com/*, the proxy would return data from https://my-whitelisted-api.com/*.
Is there any easier alternative?
Most of the Azure services where you host your app has a single outbound ip or a range of outbound ip-addresses that can be whitelisted, but it's hard to know if that works in your case as you did not mention in what Azure service you host your app.
A generic solution could be that you provision an Nginx proxy in Azure Container Apps. Then you will will have the Container Apps Environment public ip address as outbound ip to whitelist. Beware though that anyone can call your proxy from any ip, which means that you are completely disabling the protection they put in place by whitelisting ips and opening up their API to the whole world. So without knowing your circumstances, this would probably not be recommended.
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.
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.
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.
I set up a simple asp.net web forms test site for learning Azure, with a simple DB. Works fine locally. I deployed it to Azure. Then went through learning curve on the need to separately deploy the DB, link the resource, check connection strings and so on.
There's an issue, where the program on the site gets an error. I'm going through many paths to try to diagnose it. This question is about one specific path.
Several articles say that for the website to use the DB, I have to add the IP address of the website to the allowed IP addresses of the DB server.
https://azure.microsoft.com/en-us/documentation/articles/sql-database-create-configure/
However, I can't find the IP address for my FREE Azure website. When I researched this, it looks like there is no available fixed IP address for free websites.
So either:
1) I need to know where to get the IP address for the free website, or
2) there is some way to use Azure SQL in free websites without having to
designate an allowed IP address, or
3) something completely different.
Any help with this would be appreciated.
Thanks!
UPDATE: Below is all I see on the database configuration page, i.e. no firewall rules. However, I became convinced that the "Allowed IP Address" requirement must be finessed automagically in Azure, and so that was likely NOT the problem, which made me look more closely at the connection string, which WAS the problem. Basically one day of newbie learning curve, which I'll have to sleep on and try to understand more tomorrow.
There's an option to allow Azure services when you configure the database firewall. Check if that's checked. Also, posting the actual error message will help.
You don't need to do that for things that are hosted within the Azure platform.
Under the Azure SQL Server Firewall (Preview Portal) settings, ensure that the Allow access to Azure services is turned on:
Alternatively, via the Old Portal, the setting is found via:
Databases -> Servers -> Configure