Protect APIs

Pixi API is a deliberately vulnerable, publicly available API that was created as part of the OWASP DevSlop project to demonstrate common API issues. Because the API is intentionally and predictably vulnerable, it is easy to see how API Firewall helps to cancel out the vulnerabilities.

Go to our Resources repository in GitHub to find the resources and the detailed instructions as markdown readmes for several Kubernetes environments on how to deploy the sample firewall configuration. The readme of the repository explains what kind of resources are available.

The setup has been tested on the Kubernetes engines of the following public clouds and Kubernetes environments:

• Amazon Web Services (AWS)
• Amazon Elastic Container Services (ECS) on AWS Fargate
• DigitalOcean
• Google
• IBM
• Microsoft Azure
• Minikube

Use the following guides and resources to protect the Pixi API:

• Generic Kubernetes guide: Use these resources to deploy API Firewall on a Kubernetes service in AWS, DigitalOcean, or IBM.
• Generic Kubernetes with Helm charts guide: Use these resources to deploy API Firewall on Kubernetes using Helm charts.
• Amazon ECS on AWS Fargate:
  • Use this guide and these resources to deploy API Firewall from a sample task.
  • Use this guide and these resources to deploy API Firewall using an AWS CloudFormation template.
• Google Kubernetes Engine (GKE) guide: Use these resources to deploy API Firewall on GKE.
• Microsoft Azure Kubernetes Service (AKS) guide: API Firewall is available as a container image, API Firewall Container, in Azure Marketplace.
• Minikube guide: Use these resources to deploy API Firewall on Minikube.

You can replicate the sample resources provided in our Resources repository in GitHub to deploy your own APIs to your existing ecosystem. If you do not have an existing environment, see the documentation of the environment you want on how to create one.

Resources and guides for the following environments are available:

• Amazon ECS on AWS Fargate:
  • Use this guide and these resources to deploy API Firewall from a sample task.
  • Use this guide and these resources to deploy API Firewall using an AWS CloudFormation template.
• Generic Kubernetes guide: Use these resources to deploy API Firewall on a Kubernetes service.
• Generic Kubernetes with Helm charts guide: Use these resources to deploy API Firewall on Kubernetes using Helm charts.
• Google Kubernetes Engine (GKE) guide: Use these resources to deploy API Firewall on GKE.
• Microsoft Azure Kubernetes Service (AKS) guide: API Firewall is available as a container image, API Firewall Container, in Azure Marketplace.

The guides use Pixi API as the example, and they start from the very beginning of importing APIs to the platform. You can skip any of the steps in the guides that you have already completed.

1. Follow the instructions in the guide for your environment to make sure you are meeting all the prerequisites.
2. Add the protection token you created to as the value of the protection token variable. For more details, see Protection token variable
3. Configure the mandatory API-specific API Firewall variables for the API Firewall instance:
   • LISTEN_PORT
   • TARGET_URL
   • SERVER_NAME
   • LISTEN_SSL_CERT
   • LISTEN_SSL_KEY

   By default, the listener interface of API Firewall only accepts HTTPS connections, and you must specify the variables LISTEN_SSL_CERT and LISTEN_SSL_KEY. If you want to use HTTP connections instead, you can add the variable LISTEN_NO_TLS to your API Firewall configuration. In this case, HTTPS connections are ignored and TLS configuration is not required. For more details, see Switch API Firewall to use HTTP connections.

4. If you want, configure the following optional variables for the API Firewall instance:
   • GUARDIAN_INSTANCE_NAME
   • GUARDIAN_NODE_NAME
   • GUARDIAN_INSTANCE_NAMESPACE
   • GUARDIAN_INSTANCE_IP
   • GUARDIAN_INSTANCE_SERVICE_ACCOUNT
   • PLATFORM_HOST
   • PRESERVE_HOST
   • LOG_LEVEL
   • ERROR_LOG_LEVEL
   • LOG_DESTINATION

   For more details and more environment variables to configure, for example, connections between the protected API and the API Firewall instance, or the API Firewall instance and your backend services, see API Firewall variables.

5. Add passing TLS configuration files to the API Firewall container in your deployment scripts:
   • Add the files directly to the API Firewall Docker tailored for your API. For example, you can retrieve the files from a secrets manager or generate a self-signed, temporary cert/key pair at each build and place them into the built image:

     FROM 42crunch/apifirewall:v0.16.7
     COPY /*.pem /opt/guardian/conf/ssl/

   • Mount the images from Kubernetes secrets:

     volumeMounts:
         - name: certs-volume
             mountPath: /opt/guardian/conf/vhost/ssl
             readOnly: true
     ...
     volumes:
         - name: certs-volume
             secret:
             secretName: apifirewallcerts

   How to generate certificate/key pair for TLS configuration?

   If you do not already have a certificate/key pair to use for the TLS configuration, you can create one using, for example:

   • OpenSSL:

     openssl req \
         -newkey rsa:2048 -nodes -keyout firewall-key.pem \
         -x509 -days 30 -out firewall-cert.pem
     

   • The cert-manager in Kubernetes-based environments:

     apiVersion: cert-manager.io/v1alpha2
     kind: Issuer
     metadata:
         name: selfsigned-issuer
         namespace: dev
     spec:
         selfSigned: {}
     

   • IDCA, a 42Crunch utility that generates certificates signed by a self-signed CA. Run ./idca -h for help.

   For more details, see TLS configuration.

6. Run your deployment scripts to run API Firewall. The API Firewall instance starts and API Protection is activated for your API.

To invoke your API and its operations, your API consumers must now call the listener interface of the API Firewall at https://<SERVER_NAME>:<LISTEN_PORT>. All API calls go through API Firewall that filters out the unwanted calls and only lets through the calls that should be allowed based on the OpenAPI definition of your API.

When API Firewall is launched, it performs the following steps:

1. Checks that the required environment variables have been defined in the configuration files.
2. Retrieves protection configuration that matches the defined protection token from 42Crunch Platform.
3. Starts the reverse proxy.

In the rare case that an API Firewall instance receives a configuration that is not valid and cannot be run, the instance and its Kubernetes pod immediately exit and this is logged in your Kubernetes logs. You can also see this in the details of the API, both in the API collection view and on the Protection tab of the API.