I am making requests to the Google Geocoding API within my node project. In production the project is running on Containers (AWS Elastic Container Service) which means the IP address for the service can change automatically - this means that I constantly have to update the IP whitelist in my Google API Key.
IP whitelisting is the only means by which I can secure the API Key. Furthermore, if I don't secure it then the key shortly becomes useless because of unauthorized use from another source.
Is there a practical solution to securing the connection with the Geocoding API from an application running on containers?
Thanks in advance for your help!
When you create your key for the Geocoding API you can simply add no website restrictions. The security implication is that your key is now usable from anywhere so the import of keeping it safe is a bit higher.
Related
I'm using Google YouTube Data API v3 on a PHP based website and it works fine if there is no access restriction. APIs are called only from the server and not from client side.
However, if I setup a IP based restriction then all requests are blocked. It seems, that I set a wrong IP. I have already double checked the IP on my server and with ping as well and it is correct.
Any idea, what can be the problem?
I basically have an API that is going to be used with a web app and a mobile app. I don't want the API to publically available, where should I deploy it then? is there a way without using AWS? Thanks, Nav :)
There are multiple ways of doing this. This is a sensitive topic, as this is an opinion-based field.
However, I will try to answer below - and challange your way of approaching this.
It really depends on your 'operational' skills, funds, need for security, deadline(s) etc.
Basically you need to make an endpoint available on the www, without everybody being able to connect.
You could either:
Deploy a virtual machine or web app. in Azure/AWS/GCP/... and whitelist the IP's you need to connect from.
Rent a VPS from any provider, and deploy your application here - Again, whitelisting. (Edit: Not phones, since this IP changes constantly. A proxy can be implemented here (potential bottleneck), or any authentication mechanism like OAuth, JWT, Certificates etc. can be implemented either on the ingress controller (e.g. NGINX) or the application itself.)
Deploy the application on your Home-PC, order a static IP to your home and make a forwarded port and set up security on your premise (not recommended, and raises and bunch of other headaches)
Get in touch with a company that hosts web applications (Can be quite expensive)
Based on the limited information provided in your question, there is a ton of options, nice-2-haves and factors that comes in to play when choosing the setup that suits your needs.
You should also consider; VPN usage, Backup/disaster recovery, data leaks, redundancy, the need for future deploys, how you would access your environment in six months....
I hope this answered your question, but also raised a few for you to answer yourself.
Finally, I'd recommend you looking for inspiration here.
EDIT:
Question:
Whitelisting mobile IP's.
VPS selected.
Answer:
This becomes quite a task when mobile phones tend to change IP's frequently.
Since you are looking further into the VPS setup, you are more in control of the setup and can choose to look into OAuth and JWT.
Links:
OAuth - https://oauth.net/getting-started/ https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps
NGINX JWT - https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-jwt-authentication/
So - At the end of the day, you can make your app use a proxy (potential bottleneck) and whitelist this IP, or make the endpoint open (any -> 443) and implement an authentication mechanism like the ones mentioned above.
Consider implementing a DMZ zone for incoming traffic from the web.
https://en.wikipedia.org/wiki/DMZ_(computing)
and put your application behind this zone, making sure that the only the DMZ zone is facing the internet, and the server hosting your application is talking to the server in the DMZ.
Again, this is quite a big topic and is hard to simplify to a stackoverflow post.
If you are hosting the app on AWS you have a couple of options.
API Gateway now supports private endpoints. These endpoints can not be called via the public internet. That means if your app is hosted on AWS only the internal services of the app can call the end point. i.e. front end to database etc. I've used this method for internal micro services such as placing in house app data onto kinesis streams.
Alternatively, if you don't want to use API Gateway you have lots of options. Most of which would involve you creating rest APIs from where ever you plan on hosting your code. This could be on the server it's self or some sort of container.
API Gateway Private Endpoint Reference:
https://aws.amazon.com/blogs/compute/introducing-amazon-api-gateway-private-endpoints/
I have an application that uses spring boot for a backend and Vue.js as a front end. I have packaged the app into a jar file and deployed to PCF with ease. The problem is the application uses API Keys from https://developer.clashroyale.com/#/getting-started ...these keys require you to input the IP Address that will be used...
Obviously my key will not work unless I give the correct IP address, so how do I retrieve the IP Address for my PCF application so I can generate the proper API Key?
Also, the documentation says that the IP will change with every deployment of my application... Which prompts the question :
Is it impossible to use API Keys that require static IP Addresses with PCF applications?
I have deployed this same application to amazon AWS and it worked because I have a static IP Address that I can use to register a key. I prefer to use PCF, but am having trouble setting it up.
I don't think you will be able to use that API on the PCF platform. Every time you either cf restage or anything to cause the container to be rebuilt/redeployed, the IP will change.
So in short yes, it's impossible: https://docs.run.pivotal.io/marketplace/external-ips.html
Your app will be run on any number of Diego Cells, which all have different IP addresses. There are a couple ways that traffic can leave your app and the Cell.
In some cases, outbound traffic may go through a NAT, in which case the number of possible IPs may be small and the IPs may not change often (or at all). In other cases, traffic may leave directly from the Diego Cell on which your application is running. In this case, there's a lot more IPs & the IPs will change any time your app is restarted.
If you're talking about some general installation of Cloud Foundry, it will depend on how the operators for that environment have set up the traffic to flow so you'd need to confirm with your operator to be certain.
If you're talking about Pivotal Web Services, outbound traffic will originate from the IP of the Cell on which your app is running. See the link in Francisco's post.
Having said all that, there's a hack that you can use to work around the behavior above. Route your traffic through a proxy. Traffic coming out of the proxy can be made to have a fixed IP address.
On PWS, there is a service in the marketplace available to do exactly this. It's called QuotaGuard.
https://docs.run.pivotal.io/marketplace/services/quotaguard.html
You don't have to use that service though, you could use any other service provider or you could even set up your own proxy. I would recommend using a service unless you know exactly what you are doing though. Setting up & securing a proxy is not trivial and an improperly secured proxy is bad not just for you as the owner but the whole Internet.
We are calling Google api via https://www.googleapis.com for social login on our website. Everything works fine upto staging , however on Live server due to firewall restriction api calls are throwing socket exception.
What is the best way to configure our live server to allow connectivity to Google.
Is there a list of ip addresses . How can I make sure it's all up to date.
Note: You must be using Google Maps for Work (paid) in order to host maps on a website that is behind a firewall. Otherwise you are in breach of the terms of service.
As for configuring your firewall, Google will provide you with all of the settings that are needed. You don't need to make constant changes to keep it working.
The primary source of information for configuring your firewall is found here: https://developers.google.com/maps/documentation/business/articles/prelaunch_checklist#firewall
Configure Firewall to Allow Access to the Google Maps API Services
Why it's important: The Maps API services use a variety of domains, some which do not belong to the *google.com domain. If you are behind a restrictive firewall, it is important you understand which Maps API services use which domains.
Failure to allow access to the correct domains will cause API requests to fail, which can break your applications. For a complete listing of domains used by the Maps APIs, please consult our portal resource (login required):
Log in to the Google Enterprise Support Portal
The support portal is only available to Google Maps API for Work users.
Navigate to the "Resources" tab
Select the Resource called "List of domains used by the Google Maps API Family."
You should allow your applications to access these domains.
Please note that we do not recommend managing firewall restrictions by IP address, as the IPs associated with these domains are not static.
I have started using Heroku's addon for ElasticSearch, Bonsai. I want to create a backend search for several categories on my website. Since this is a backend only service, and may contain sensitive information, how do I limit the IP addresses connecting to the Bonsai server that Heroku has provided me to only the IP address/range of my web servers.
Note that my web servers are running on private hardware and are not hosted on a cloud service. I am also not using any other web service on Heroku, so I prefer not to use a Ruby answer to this.
I ended up working with the Bonsai team to set up a custom solution on their end that required a username and password combination to access any data on my hosted search.