- Need to run many decentralized APIs ? Do not want to use a central gateway ?
- Want to protect your API or Application with Application Firewall functionality ?
- Throttle heavy load to protect your APIs and services ?
- Want to deploy API Gateway next to each individual API, as a "sidecar" in a service mesh ?
Ceptor Microgateway can be deployed both as an API Microgateway, and a regular Web Gateway. It provides the full Ceptor functionality without limitations.
You can run it both as a standalone process, and run in in a Docker Container, either right next to the API/Application it protects, or on a separate machine close to it.
Ceptor Microgateway can be deployed both in standalone mode, with all needed modules embedded inside it, and it can be deployed in connected mode, where it uses an existing Ceptor Server cluster for handing sessions, authenticating users as well as configuration and administration.
Ceptor Microgateway requires limited resources, the full standalone version can run with less than 200Mb memory, using down to below 50Mb when idle and still have plenty of power to protect your applications and APIs.
Ceptor Microgateway in its standalone mode includes the following modules:
as well as an embedded or external database for APIs (if used as an API Microgateway).
What is an API Microgateway ?
An API microgateway is a proxy (reverse and regular) server which sits close to an individual microservice.
As a result, it provides value to the developers by extracting governance, discovery, observability and stability in a reusable component and gives value to the operators by exposing the Policy Enforcement Point (PEP) and Security Controls in a centralized control panel. And, thus, you end up with a system that is a service mesh allowing one to externally control service monitoring, availability, tracing, request (version) routing, resiliency testing, security and policy enforcement, etc., in a consistent way across all services in an enterprise.
What is a Web Microgateway ?
A Web Microgateway, is a reverse proxy server that is deployed next to an individual application.
It can protect access to the application, handle authentication (ranging from userid/password and multifactor or national IDs to biometric identification) - it can handle authorization (RBAC and ABAC) on behalf of the application.
A primary reason for choosing a Microgateway instead of a regular centralized Gateway is to separate deployment, responsibility, governance and provide increased resilience.
Deploying Ceptor Microgateway
Within the Ceptor distribution, you can find two configuration files;
The first one tells ceptor which modules to start, while the second one contains the configuration for all the modules. You can change this as needed.
You can start ceptor by running:
At Docker Hub, you can find the Docker Image
ceptor/ceptor-base-microgateway:latest which contains a deployment/configuration for a Ceptor Microgateway configured as an API Gateway along with an embedded Derby database - connect to Ceptor Console at https://localhost:4243 and to the gateway on port 8443.