I looked through all the documents of the API Gateway but was not able to find any reference of the security features that Google API Gateway provides - for example does it provide any protection from DDOS attacks, or OWASP security features. Any guidance will be helpful.
It seems you got confused between API Gateway and Cloud Armor.
Cloud Armor is the one that protects you from DDOS attacks. You can also find the documentation here.
Related
I know this is not a programming question, but a valid questions to decide the architecture.
I am working on creating APIs would be used by third-party developers. This means the developers needs to sign-up for a plan (possibly using Stripe), get API key and start making requests.
I am leaning more towards using https://aws.amazon.com/api-gateway/ for the benefits it provides around API management, security (via Cognito) and having a developer portal (https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-documenting-api.html). In my observation so far, Cloudflare API gateway does not provide these benefits. Another benefit is using CDK to manage the entire stack programmatically.
When comparing serverless functions, I am more interested in leveraging Cloudflare workers because of
No cold start issue.
Better pricing.
However, I am unsure about a few things
If a request comes to API gateway and authenticates perfectly, how do I securely invoke Cloudflare worker?
I am sure there would be some latency added between the 2 systems. Are there any ways to minimize the latency?
The guidance is very much appreciated.
Thank you
Recently i read and article regarding securing of web app with API gateway. I just want to confirm some ideas like Sniffing, framing etc are possible threat in rest API case as well?
Here is the article
I am working in data platform on Kubernetes. Therefore, I will need to install
several databases like Ceph (or Minio), Postgresql, Elasticsearch
A kafka cluster
a SQL engine like Trino (former PrestoSQL)
several api servers
Multiple users and applications (internal to Kubernetes or not) will need to be authenticated and authorized to use theses components above.
For authorization I have found a project like Open Policy Agent which fits my wish to have a centralized and unified way to control it.
I would like the same thing for authentication but I am still looking for it.
There are different ways to authenticate, the most interesting ones being:
TLS certificate
OAuth2
Kerberos
But all the above components does not implement these methods.
For instance, I was interested to use Keycloak. It is perfectly suited for API servers, Kafka but not for Postgresql.
Do you know some solutions, alternatives to my problem?
Like Jonas good mentioned in the comment:
This totally depends on what your systems support. It is easiest if they support JWT-tokens for authentication, then the microservices can use its serviceAccount.
One of the solutions might be to use service-mesh, like istio and JWT (JSON Web Tokens). Here is also istio documentation about JWT. In simple terms, microservice will generate a JWT and istio will check if the token is correct. This guide shows exactly, how Istio Authorization Policy works.
Here you can find a very good article that explains how such authorization works step by step. It presents various methods of implementation. It shows their strengths and weaknesses.
It's also worth taking a look here. The official istio security documentation explains how to approach the subject of authorization. You can find there all supported authorization methods.
You can also create your custom action to delegate the authorization to external system. Here is the guide, how you can do it.
Kubernetes also supports 3rd party authentication tools: Keycloak, Auth0 or Google Auth. Here are guides, how to secure Kubernetes clusters with:
Keycloak and istio
Auth0 and Istio
Google Auth and Istio
I have two webapi projects which will be deployed as two different websites on the same server - server/site1 and server/site2. They both use token authentication. Can I have a third webapi project with just the token endpoint that is deployed at server/tokensite so that the token retrieved from here can be used for authentication on site1 and site2?
Your Problem
I have two webapi projects which will be deployed as two different websites on the same server - server/site1 and server/site2. They both use token authentication. Can I have a third webapi project with just the token endpoint that is deployed at server/tokensite
I would prefer to deploy on same server, but using sub domains:
site1.example.com
site2.example.com
auth.example.com
This gives you the flexibility to move things around servers more easily.
so that the token retrieved from here can be used for authentication on site1 and site2?
Yes you can, but as I already mention I wouldn't do it in the same domain.
So it seems that what you are trying to implement is Single Sign On(SSO)
Single sign-on (SSO) is a property of access control of multiple related, yet independent, software systems.
Conversely, single sign-off is the property whereby a single action of signing out terminates access to multiple software systems.
Other shared authentication schemes such as OpenID, and OpenID Connect offer other services that may require users to make choices during a sign-on to a resource, but can be configured for single sign-on if those other services (such as user consent) are disabled.
So to achieve SSO you can use OpenID Connect:
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.
Possible solution
I don't advise you to implement your own solutions, instead delegate it to an Authentication provider, or use an Open Source package to implement it.
It seems you are using DOTNET, thus I would recommend you to read this quick start on their docs, that guides you through of setting up SSO in a new project with some official libraries.
In this quickstart, you'll learn how to implement sign-in with Microsoft using an ASP.NET MVC solution with a traditional web browser-based application using OpenID Connect. You'll learn how to enable sign-ins from work and school accounts in your ASP.NET application.
Alternatively you can use SSO from Azure Active Directory.
Single sign-on (SSO) adds security and convenience when users sign-on to applications in Azure Active Directory (Azure AD). This article describes the single sign-on methods, and helps you choose the most appropriate SSO method when configuring your applications.
For anyone reading this, but using other language, see some examples of SSO packages for:
PHP.
Python.
NodeJS.
Going the Extra Mile
Once you are deploying your own solution I would recommend you to invest heavily in securing it. For an API serving a web app you can employ several layers of defense, starting with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution. If you want to learn and understand why is important to secure properly an API, you may want to read this series of articles, that will teach you how API Keys, User Access Tokens, HMAC and TLS Pinning can be used to protect the API and how they can be bypassed. While the series of articles are in the context of a mobile api, lot of it is still valid for a web api.
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
I'm developing a web API that will be called by other web apps in the same Azure host and also other 3rd party services/ app. I'm currently looking into API Apps and API management, but there are several things unclear for me regarding security implementation:
Does API App need to have authentication when implemented with API management? If yes, what are the options? This link http://www.kefalidis.me/2015/06/taking-advantage-of-api-management-for-api-apps/ mentions "Keep in mind that it’s not necessary to have authentication on the API App, as you can enable authentication on API Management and let it handle all the details." So that means having the API App authentication to public anonymous? But then someone who knows the direct URL of the API App can access it directly.
What is the best way to implement API Management security? The one mentioned in the tutorial (Having a raw subscription key passed in the header) seems to be prone to man in the middle attack
What advantages does API App add instead of implementing with normal Web API project?
Thanks in advance.
I can answer from API Management perspective. To secure the connection between API Mgmt and your backend (sometimes called last-mile security), there are a few options:
Basic Authentication: this is the simplest solution
Mutual certificate authentication: https://azure.microsoft.com/en-us/documentation/articles/api-management-howto-mutual-certificates/ - this is the most common approach.
IP Whitelisting: if you have a Standard or Premium tier APIM instance, the IP address of the proxy will remain constant. Thus you can configure firewall rules to block unknown IP addresses.
JWT token: if your backend has the capability to validate JWT tokens, you can block any callers without a valid JWT.
This video might also be helpful: https://channel9.msdn.com/Blogs/AzureApiMgmt/Last-mile-Security
I think the document meant you can do the JWT token validation in APIM. However, to prevent someone calling your backend directly, you'll have to implement one of the options mentioned above in your Api Apps