API Management & Security Series — 3Scale — Part 1 — Overview
Opening
As most of you probably know, in the last couple of years APIs became a force to be reckoned with; Every organization that handles a large amount of data, have several different strategic clients that would like to consume different information that it holds, or maybe have different internal departments which designed to work together on different projects, that fertilizes each other — already have a decent arsenal of exposed APIs for its many purposes.
In today’s reality, APIs are not only there to help support other product functionality — they are the product. APIs holds the gates to some of our most used resources by our clients, our partners, and our internal sub-departments.
I’m not going to dive-in too deep on the different kinds of APIs that organization olds, or the many protocols that enable us the usage of APIs in the first place, but I do recommend on some references that I found very informative and easy to understand right here:
My main focus is going to be on the right way to manage and secure APIs in cloud environments.
Every exposed service which we would like to deploy on our cloud infrastructure (and it doesn't matter if its a hosted-cloud or on-premies) requires a certain amount of “barriers” that would protect it against a malicious attacker/user/competing organization and so on that would like to harm our service.
Furthermore — different attackers may have different agendas in their mind, here are the main ones which are most common today:
- Damage our services’ availability (Denial of our service)
- Steal some of our valuable data (Secrecy of information)
- infiltrate our organization's internal networks
Each of these can be achieved if our exposed services will be unproperly protected, and APIs aren’t any different.
API Management perception
As more and more active services are getting implemented in cloud environments (serverless deployments/s2i deployments/cloud-based CI-CD pipelines/redesign of monolithic legacy apps to microservices architecture etc.), it is becoming a great concern to govern all of them with the same mindset —
“monitor the requests to the API, enable/disable access to sensitive information to different users based on roles, verify each source that tries to access the service, control the rate of the calls to the API”.
These few guidelines are what makes the API Management tools out there today so effective. All of them follow these main rules which in turn enable us to deploy much more secured APIs and expose them to our needs with relife.
3Scale — Red Hat API Management
As I already mentioned in my prior article, I'm a red hat cloud security consultant, and during my work, I came into Red Hat API management tool — 3Scale.
3Scale is an entirely OpenSource project that Red Hat acquired in 2016 to enable customers to expose their APIs in a much more secure manner.
3Scale Architecture composed of 2 main components
1.3Scale API Management Platform (AMP)— the brain of the product; Keeping it simple — every configuration/capability that you want to implement will be done using that component. The AMP can be deployed in a variety of ways, most common are:
1.1. Centralized deployment — one AMP for the entire organization and the 3Scale management team that works with the different API-providers to expose their APIs via 3Scale
1.2. Multitenant deployment — one master AMP, and many sub-managers, each dedicated to a specific tenant, and the management is done mostly by the API-providers themselves.
NOTE!!! In the following articles, I’m going to show both deployments on Openshift 4.x
2.APIcast — API Gateway — earlier we called the AMP “the brain”, so it’s only logical to call the APIcast “the muscle”; The APIcast is the gateway that enforces every configuration done in the AMP, and does the actual protection of the API. Same as the AMP, it can also be deployed in centralized tenant and grant network access to every other project or be deployed in a multi-tenant deployment and be managed by the API-providers team.
NOTE!!! I’m not diving too deep right now because that article is meant to be an overview. I’ll show each of these components in the following articles to come
3Scale components can be deployed in a different variety of ways, and not only on Openshift clusters, even though it’s definitely the easiest way using Openshift operators; Other options may include: AMP on Openshift, and APIcast on VM, and vice versa / high availability for each component separately (APIcast or several of the AMP containers) / a hosted environment or On-premise cloud, etc.
3Scale — API Management Security capabilities
In my eyes, that is the most important section in an API Management implementation (of any kind).
API Management tool grants us a scalable, homogeneous security platform that enables us to secure many of our organization’s APIs in one place, and enforce our security compliance to our entire exposed APIs with enough flexibility to make custom adjustments for each unique API based on our needs.
Take a look at the following table to get a better understanding of some of the basic security capabilities that 3Scale specifically enables us;
Using 3Scale we can implement (with minimal to no effort) uniform authentication mechanisms (API-Key based authentication/OIDC based authentication using RH-SSO etc.) so that the developers won’t need to develop it themselves while maximizing their time to develop actual business logic for our organization.
Using 3Scale we can specify rate-limiting access policy that will track every request to our API, monitor it, and block access from specific sources if it sends too much traffic in somewhat suspicious behavior, and send alert to our SOC to investigate such behaviors.
We can also define which type of user would be able to access each of our APIs method using application plans that the APIcast will enforce on each request;
I’ll finish the basic part with an example — we have an API with two GET methods and one POST method. Using 3Scale we can create two different plans: “Basic” and “Premium”; the latter can access both methods with no limits, and the first one will be able to access only the GET methods (“Read-only” access policy), up to 10 times an hour. Each user that will want to register will need to be approved by the API-provider and the basic one will be monitored so that every time someone sends more then 8 requests an alert will be sent to the SOC team.
Nothing of that is a hard task for 3Scale algorithm, it’s not hard to implement them using 3Scale, and most importantly — nothing needs to develop every time by the developers for each API separately. Using automation (using 3Scale management API with Ansible for example), all that security can be gained in a couple of minutes to our entire organization. And I only talked about the basic options.
I hoped you enjoyed that article, and that is the last one that going to be “just words”, next up I’ll show you some real demos with detailed explanations on how to do it yourself, and I’ll also get into some more interesting advanced security implementations that I haven't even talked about yet.
