In this lab, we are going to deploy the Microgateway in Kubernetes and protect a backend with an OpenAPI spec.
Overview
Goal | Configure the Microgateway to protect a backend service by enforcing an OpenAPI spec. |
Notes | Without a valid license, Airlock Microgateway runs as Community Edition. For more details see Features and support. |
Preparation
- Deploy the Kubernetes exercise
- Run the following commands:
- The exercise has been deployed successfully.
The exercise does not contain any licenses. Therefore, Airlock Microgateway runs as Community Edition
For more details see Features and support.
To run the exercise as Premium Edition, copy a valid license to .templates/microgateway/secret/microgateway.lic
and execute kubectl apply -k .
to re-deploy the Microgateway.
Instruction
- Configure Microgateway to enforce the OpenAPI spec
- Edit Microgateway's configuration file.
- For the mapping openapi-petstore-api:
api_security.openapi.spec_file: /config/openapi-petstore.json
- Apply the new configuration.
- Deploy the Microgateway with the new configuration.
- Check the status of the Microgateway pod.
- The Microgateway enforces the OpenAPI spec and protects the backend service.
Edit the file config/config.yaml
and configure the following settings:
Use the (Microgateway) DSL reference to accomplish this task.
After modifying the configuration file, apply the new configuration by running the following command:
- Send requests to the backend
- Connect to the website:
- Open the URL in your browser: https://<MINIKUBE_IP>/
- Expand PUT /pet Update an existing pet
- Click Try it out
- Click Execute
- The response code is 200 and indicates that the request has been processed successfully.
- Replace the content of the example value textfield
- Original:
"name": "doggie",
- Value from above:
"name": ["doggie"],
- Click Execute
- The response code is 400 and the response code contains a request id from the Microgateway.
- Watch the logs of the Microgateway pod.
- The following log messages could be noticed when sending an invalid payload:
- Useful information for troubleshooting
- Check also the position key in the log message to understand the reason why the OpenAPI filter blocked or rejected an HTTP request/response or could not read the OpenAPI spec. file.
- For every request handled by the filtering engine, a log message with the
"log_id": "WR-SG-SUMMARY"
is logged. This log entry might also contain helpful information.
The difference to the original request payload is that the name is sent as a list.
"log_id":"WR-SG-SUMMARY", ...,"mapping":"openapi-petstore-api", ...,"action":"blocked","attack_type":"Noncompliant API usage","block_type":"OpenAPI", ... "log_id":"WR-SG-BLOCK-115", ... "mapping":"openapi-petstore-api", ..."attack_type":"Noncompliant API usage","block_type":"OpenAPI","constraint":"Type mismatch","th_mode":"BLOCK","position":"RequestValidator.Body.name","message":"Value is not a String"
It explains that the request has been blocked. The reason is that the OpenAPI spec defined name as type string.
In case that you run Airlock Microgateway as Community Edition, this request is not being blocked. For more details see Features and support.
The WR-SG-SUMMARY
log message indicates that in the key action
.
"log_id":"WR-SG-SUMMARY", ..., "action":"allowed", ...
Cleanup
- Delete Kubernetes resources from previously exercises or solutions
- Run the following commands:
- All relevant Kubernetes resources in the namespace have been deleted successfully.