Users of ours running their code, on premise, access data we provide them via GCP's BigQuery API. It's a REST API with a client library wrapper.
We want to protect access to the BigQuery API backend with a firewall (in order to whitelist client IP's etc). What are the best options, preferably some GCP solution? Reading Google's documentation it's not clear if I can include the client's IP address in a GCP VPC, or if there's another way of doing it. Cloudflare also seems like an option, but I'd prefer to use a GCP offering.
Related
I have built an API to my web application so that customers can access certain functionality without going through the dashboard. I have secured it by providing an API key to each customer that identifies them and restricts the IP address from which they can connect.
I have now had a request from a customer to allow them to access this API from their Salesforce platform. I don't know much about Salesforce, and when I asked them to let me know their IP address so I could create their API key, all they could give me was the list of reserved IP addresses published by Salesforce. This IP space is huge (millions), covering all of Salesforce, meaning that if someone gained access to the API key they'd be able to use it from any Salesforce account.
I have read some things about Salesforce having an OAuth service and having some kind of Application Connect service, but it mostly seems to be designed around allowing 3rd parties to connect to Salesforce - I'm getting a bit bogged down trying to determine if this is any use in my scenario (which requires authentication in the other direction).
I'd be grateful for any insight into whether there's something more specific I can do identify a particular Salesforce customer beyond simply putting dozens of CIDR blocks in my API key. I could ask my customer to identify themselves in the referer header when they call my API, for example, but of course that's trivial to spoof.
Thanks.
IPs can be spoofed too
Salesforce has a concept of "protected custom settings". You could make a "managed package" (Salesforce plugin, but you don't need to distribute it on their appexchange, Google Play/App Store equivalent), install it for the client and then enter the API key to the setting in a way that even client's sysadmins can't read it.
It'd be bit of work to set it up but might pay off if you think you'll get more customers on the platform.
How about a crude but effective iframe? or a link to your page they'd embed somewhere in their app?
Do you have just api keys? If you'd expose OAuth2 endpoint SF users could login to your app and then SF code could use access_token they got back instead of api keys. Or maybe you can protect access with certificate? Calling app would have to sign requests with a certificate. Client could upload it to their SF, you'd upload to your app...
You could demand the API calls to include the user's SF "session id" and you could use that to run some queries against source SF org. Org Id, user's login history etc things that are impossible to tweak even by sysadmins...
I am hosting a simple static website via Google Bucket right know:
Does the Bill look familiar to you? I am surprised by the high usage numbers.
Does there exist a Hitcounter for GoogleBucket-Websites?
How can I secure my bucket website with SSL?
I tried to follow the Loadbalancing Manual, but somehow it doesn`t work.
As stated in the documentation
While you can serve your content through HTTPS using direct URIs such
as https://storage.googleapis.com/my-bucket/my-object, when hosting a
static website using a CNAME redirect, Cloud Storage only supports
HTTP
As you correctly stated using the loadbalancer is a recommended method to serve your content trough HTTPS. If you need help with this I would recommend you to ask another question with the details of the steps followed and the error impeding you to continue.
Using a load balancer will let you use Stackdriver to monitor the access to your account. Using Stackdriver you can get custom metrics and get the number of users entering your website.
Also discussing your Google Cloud Platform billing invoice in Stackoverflow is not recommended as it is not related to programming. If you need help with your billing you should contact the Billing support team of Google Cloud Platform.
I have hosted a S3 static site into CloudFront. That site using rest api deployed into api gateway. API gateway has not access control.
I want to protect my api from being accessed by others. Only my static site can access it. I know I can use api key but that could expose by browser console which is not expected.
Is there other way to control my api access?
Thanks in advance
I have a similar issue as well. It seems like using referer or CORS restrictions are the best way to go. However, in practice I haven't been able to make it work after trying both CORS and referer restrictions. API Gateway has automatic protection against malicious behavior like DDOS attacks according to their FAQs, but it is disheartening that I haven't found a specific solution for protecting my API gateway that is only used for my S3/Cloudfront static site.
Google Cloud allows you to use their API keys on the frontend for integrations with services like Google Maps. The way they protect those keys is through restricting the API keys to certain domains. Unfortunately, I haven't found similar functionality for AWS keys. As you know, the only way to throttle or put quotas on API gateway is through API keys, so it looks like this would be useless for a static site that can't expose those API keys publicly on the frontend.
It defeats the whole purpose of going completely serverless if I am unable to configure my serverless API Gateway the same way I could congfigure a normal backend EC2 server. For now, I've created billing alarms so I don't get surprised with a huge AWS bill if something goes wrong with my unprotected API gateway.
We have a package that we share with out customers. In the package, we have a chunk of code that does HTTP Request callouts to our central API Gateway. As of now, our API Gateway is open and accepts requests from everywhere, which is not good. I want to limit access to our users who would be using our software. The only solution I have found is using IAM and providing authorization that would require us to include our Access Keys in the package. Our users can install our package in any environment they want and we have no control over that environment. So I think a viable option is to create a generic user policy with minimal access to allow our users to call our API Gateway. However, putting access key in the code doesn't seem like a good idea. Another option is to provider our customers with access keys but that also has overhead. What is a better alternative that is more secure and easy to maintain?
You can use built-in API Gateway API Key functionality when IAM policies aren't possible.
So long as your clients could be on any infrastructure, versus limited to AWS, the API Gateway service provides a generic API key solution, which allows you to restrict client traffic to your API Gateway by enforcing that client requests include API keys. This API key interface is part of their "API Usage Plan" feature.
This document explains how to use the console to set up an API Gateway to enforce that client traffic bears an API key:
To set up API keys, do the following:
Configure API methods to require an API key.
Create or import an API key for the API in a region.
Your clients can implement a "secret storage" solution, in order to avoid putting their API keys into their source code.
For sure it isn't wise for your clients to store their API Keys plain-text inside their source code. Instead, they could use a secret storage solution, to store the API keys outside of their codebase, but still give their applications access to the secret.
This article describes an example solution for secure secret storage (e.g. secure API key storage) which grants an application access to the application secret without putting the unencrypted secret into the source code. It uses Amazon KMS + Cryptex, but the same principle can be applied with other technologies: http://technologyadvice.github.io/lock-up-your-customer-accounts-give-away-the-key/
I have an application that has a couple of features that I would like third parties business to avail of. for example the user information gets passed to us and we run ID checks and send back a token with information.
I think I can use a third party API management service like 3scale but what do I have to do on my end to 'expose' this API?
Thanks!
With AWS API Gateway, you can setup a simple http proxy to your application. Based on your needs, you can use features like auth, throttling, API keys management, client certificates etc.
Here is a blog explaining some of this.
Hope this helps, Ritisha.
As mentioned by Ritisha, API Gateway definitely can work, but it is sort of lock it.
I would recommend checking https://tyk.io/, which is an open source Gateway with commercial options. And for example it provides you Cloud version, where you do not need to expose any ports on your side at all. You just configure your API in dashboard and can just bind your CNAME record to the proxied API. This should work really well to try it out. And if you grow up this options, you can host it on your own, or use Hybrid environment, when all user requests come to your own server (no 3-rd parties), but on the other hand, have nice configuration dashboard in the cloud.
Hope it helps!