How-tos

18 mins read

Protecting APIs Exposed On Kong API Gateways

Learn how to apply access control to protect APIs deployed behind Kong API Gateways. Install necessary plugins in your Gateway. Deploy Cloudentity's Kong Authorizer to enforce policies applied to your discovered APIs.

About Kong Gateways

KongHQ provides you with two versions of a self-hosted Kong Gateway: Kong Gateway (Enterprise) and Kong Gateway (Open-sourced). Both gateways are designed to be a part of decentralized architectures that leverage automation and modern GitOps practices. With their features, you can:

  • Decentralize applications/services and transition to microservices

  • Identify API-related anomalies and threats

  • Secure and govern your APIs and services

With Cloudentity and its Kong Authorizer and plugin, you can successfully integrate your Kong Gateway with Cloudentity solutions for authorization no matter whether it is an Enterprise or Open-Sourced Kong Gateway or which deployment type you chose for your gateway.

Integration Components

Kong integration components

In the diagram above, you can see that Cloudentity is responsible for OAuth authorization for client applications and providing them with access tokens. It also provides policies and keys to the Kong Authorizer. Behind the Kong Gateway, you can have a number of services deployed that are protected by the Kong Authorizer. You need to have the Cloudentity Kong Plugin attached to the service that you wish to protect. The plugin is responsible for calling the /authorize endpoint of the Kong Authorizer. It also allows the authorizer to fetch Kong Gateway services that can be later on passed to Cloudentity so that you are able to assign authorization policies to the APIs of your choice.

When a client application calls a protected service and its request contains an access token dervied from Cloudentity, Kong Gateway invokes the Cloudentity Kong Plugin so that it can communicate with the Kong Authorizer to authorize the client’s request. The authorizer validates all authorization policies that it fetched from Cloudentity for the given API. After a successful authorization, the Kong Gateway executes the API from the protected service.

The Kong Gateway itself can also be protected with RBAC, Basic Auth, or OAuth 2.0, depending on your Kong subscription and security requirements. For details, read Authenticating to the Kong Admin API.

Cloudentity Kong Plugin

Cloudentity Kong plugin is a LuaRocks plugin that is executed during the HTTP request/response lifecycle.

This plugin, in particular, is responsible for authorizing access to an upstream service. When you add the Cloudentity Kong plugin to your service, every request made by a client application to this service runs the plugin. The plugin assembles the request data and sends a query to Cloudentity’s Kong Authorizer that is responsible for comparing the request against an authorization policy defined for a given endpoint. After policy validation, the authorizer can respond whether the request should be allowed or denied.

Integration with Kong Gateways

KongHQ provides several possibilities for deployment of their gateway, but you can integrate Cloudentity and its Kong Authorizer with Kong Gateway no matter which deployment type you chose for your gateway. The requirement is that your Kong Authorizer deployment can communicate successfully with your Kong Gateway, whether it is, for example, deployed in a Docker container or in Kubernetes with Helm Charts.

This article provides examples for both Docker container deployment and Kubernetes deployment for the Kong Gateway and the Kong Authorizer. Your Cloudentity instance, however, can be deployed anywhere. It can be, for example, Cloudentity SaaS solution, Docker deployment, or kubernetes deployment with Helm Charts.

To integrate your Kong Gateway with Cloudentity and Kong Authorizer, you will install the Cloudentity Kong plugin for your Kong Gateway and assign it to your service or a particular route. Then, you will create a Kong Authorizer in your Cloudentity instance. Once the authorizer successfully discover your services exposed by your gateway, you will be able to apply access control to your APIs.

Prerequisites

  1. Docker v1.19+ and Docker Compose installed.

  2. Access to an Cloudentity SaaS tenant

  3. Service to be protected by Kong Authorizer is deployed (this instruction allows you to deploy a mock service for testing purposes).

Deploy with Docker

The sections below explain how to set up Kong Gateway and Kong Authorizer using Docker.

Build Kong with ACP plugin using Docker

  1. Clone the docker-kong project.

  2. Add the following steps to your Kong Gateway’s Dockerfile to make sure the kong-acp-plugin is installed.

    USER root

RUN apk add gcc musl-dev

RUN  luarocks install kong-plugin-acp

    As a result, the content in the customize/Dockerfile file should look as follows:

    ARG KONG_BASE=kong:2.8

FROM ${KONG_BASE} AS build

ARG PLUGINS
ENV INJECTED_PLUGINS=${PLUGINS}

ARG TEMPLATE=empty_file
ENV TEMPLATE=${TEMPLATE}

ARG ROCKS_DIR=empty_file
ENV ROCKS_DIR=${ROCKS_DIR}

ARG KONG_LICENSE_DATA
ENV KONG_LICENSE_DATA=${KONG_LICENSE_DATA}

COPY $TEMPLATE /custom_nginx.conf
COPY $ROCKS_DIR /rocks-server
COPY packer.lua /packer.lua

USER root

RUN /usr/local/openresty/luajit/bin/luajit /packer.lua -- "$INJECTED_PLUGINS"

FROM ${KONG_BASE}

USER root

RUN apk add gcc musl-dev

RUN  luarocks install kong-plugin-acp

# Workarounds used:
#  1 - the "custom_nginx.conf*" wildcard ensures it doesn't fail if it doesn't exist
#  2 - "RUN true", see https://stackoverflow.com/questions/51115856/docker-failed-to-export-image-failed-to-create-image-failed-to-get-layer/62409523#62409523

# replace the entrypoint, add the custom template if it exists
COPY --from=build /docker-entrypoint.sh /old-entrypoint.sh /custom_nginx.conf* /
RUN true

# add the Lua files (.lua)
COPY --from=build /usr/local/share/lua/5.1 /usr/local/share/lua/5.1
RUN true

# add the compiled libraries (.so)
COPY --from=build /usr/local/lib/lua/5.1 /usr/local/lib/lua/5.1
RUN true

# add the Luarocks manifest
COPY --from=build /usr/local/lib/luarocks/rocks-5.1 /usr/local/lib/luarocks/rocks-5.1
RUN true

HEALTHCHECK --interval=10s --timeout=10s --retries=10 CMD kong health

USER kong

  3. In terminal, navigate to the /customize directory within your cloned project and build your image with the following command:

    docker build \
--build-arg PLUGINS="kong-http-to-https,kong-upstream-jwt,kong-plugin-acp" \
--build-arg "KONG_LICENSE_DATA=$KONG_LICENSE_DATA" \
--tag "kong-acp" .

    Tip

    As you can see in the command above, the kong-plugin-acp is included in the PLUGINS build argument for your image. You can, of course, define more plugins for your deployment here. After the scripts from the Dockerfile are executed, the kong-plugin-acp is installed within your image and kong-plugin-acp is present in the list of your plugins in the kong.conf file for your Docker deployment.

Once your image is ready and built, you can deploy it to a container, expose services, and add routes to them.

Deploy Kong with Cloudentity Plugin

Use the following Kong documents to quickly deploy Kong Gateway and attach a service and route to it.

  • For detailed instructions on how to run Docker images for Kong Gateway working with a PostgreSQL database, visit Install Kong Gateway on Docker

    If you chose to build your image as shown in the examples above, keep in mind that the image from the example above is tagged kong-acp, so please adapt the example from Kong docs accordingly. Also, with the instructions from KongHQ you create a network for your Docker containers. Keep in mind that all componenets - Kong Gateway, Kong Authorizer, as well as your service, must run on the same network.

  • To learn how to expose services and add routes on a mock service, see the Expose your Services with Kong Gateway documentation. If you already have a service, make sure it’s on the correct Docker network.

Kong Docker Images

For technical details on Docker images for Kong Gateway, visit:

Assign Cloudentity Kong Plugin to Service

Having deployed Kong Gateway and a service, it’s time to assign the Cloudentity Kong Plugin to your service, use the Kong Gateway Admin API:

curl -sSk -X POST https://{ADMIN-URL}/services/{NAME-OF-YOUR-SERVICE}/plugins \
     --data 'name=acp' \
     --data 'config.api_group_id={ID-OF-YOUR-API-GROUP}' \
     --data 'config.auth_url=https://kong-authorizer:9003/authorize'

Protected Kong Admin API

If Kong Admin API is protected, the request must be correctly authenticated. For more information, read Authenticating to the Kong Admin API.

As you can see, the curl request contains the following variables:

  • {ADMIN-URL} which should point to the URL of your Kong Gateway Admin API

  • {NAME-OF-YOUR-SERVICE} which should point to the name of the service to which you wish to assign the plugin

  • {ID-OF-YOUR-API-GROUP} which should point to the identifier of your API group in Kong Gateway

The request also contains the --data 'name=acp' argument, which is assigns the acp plugin to the service. Additionally, it contains also the --data 'config.auth_url=https://kong-authorizer:9003/authorize' argument which points to the URL under which your Kong Authorizer will be running.

Below, you can find an example of a request that assigns the acp plugin to an httpbin service exposed by a locally deployed Kong Gateway:

curl -sSk -X POST http://localhost:8001/services/httpbin-service/plugins \
     --data 'name=acp' \
     --data 'config.api_group_id=httpbin-service' \
     --data 'config.auth_url=https://kong-authorizer:9003/authorize'

Declarative Configuration for DB-less Setup

If your Kong Gateway is running without a database, you can use declarative configuration for your service to assign the acp plugin to your service as illustrated below:

services:
- name: httpbin-service
   url: https://httpbin.org
   routes:
   - name: anything
      hosts: [ "httpbin.org" ]
      paths: [ "/anything" ]
      methods: [ "GET", "PATCH", "PUT", "POST", "DELETE" ]
      strip_path: false
   plugins:
   - name: acp
      config:
      api_group_id: httpbin-service
      auth_url: https://kong-authorizer:9003/authorize

Create Kong Authorizer in Cloudentity

Before deploying Kong Authorizer, you must create it in Cloudentity.

  1. In your Cloudentity tenant, go to the workspace of your choice.

  2. Select Enforcement > Authorizers > CREATE GATEWAY > Kong.

  3. Provide a name and a description for your Kong Authorizer.

  4. Optionally, enable the Create and bind services automatically check box.

    Tip

    When enabled, all services protected by your Kong Authorizer instance are discovered and added to the Cloudentity service list automatically when the Kong authorizer is connected to Cloudentity. Otherwise, you need to add them manually.

  5. Follow the Quick Start instruction. Download the package for your Authorizer and check the instructions in the section below.

Deploy Kong Authorizer using Docker

  1. Unzip the package with the downloaded Kong Authorizer.

  2. In the .env file, set the KONG_ADMIN_URL to the URL of your Kong Admin API.

    Tip

    If you are testing it locally in your Docker deployment, the URL contains the name of the container where your Kong Gateway is running and the port number like shown below:

    KONG_ADMIN_URL=http://kong-acp:8001

    Note that, by default, the port for HTTPS connection to the Kong Admin API is 8444.

  3. In the terminal, navigate to the directory with your Kong Authorizer and execute the following commands:

    cat credentials.txt | docker login docker.cloudentity.io --username acp --password-stdin

    and

    docker-compose up

    The first command logins to Cloudentity docker with the credentials provided in the credentials.txt file in your Kong Authorizer package.

    The docker-compose up spins up a Docker container with the Kong Authorizer for you. In the logs for the Kong Authorizer, you should see that it starts the authorizer reload. At this point, however, your authorizer is not yet running in the same network as your Kong Gateway, so it is not possible for the authorizer to communicate with the gateway.

  4. Connect your authorizer to the same network that your Kong Gateway uses.

    In general, you can use a method of your choice to connect your authorizer to the network. You can, for example, execute the following command when the container with your Kong Authorizer is running:

    docker network connect {network} {container}

    For example: docker network kong-network 1babdf8b72a6

    Result

    Once the authorizer is successfully assigned to the same network as your gateway, you can see in the authorizer’s logs that the authorization configuration was reloaded.

    In Cloudentity APIs Management View, you can see APIs that were discovered by your Kong Authorizer. You can now apply access control to them.

Deploy with Helm Charts

You can deploy both Kong Gateway and Kong Authorizer using Helm Charts.

Deploy Kong Gateway with Helm Charts

You can use the Kong Helm Chart to deploy the Kong Gateway.

  1. Prepare the values file. You can use the official minimal setup as a template. Make sure to add the following configuration to the file:

    • The acp plugin
    • The deployment configuration
    env:
  plugins: "bundled, acp"
deployment:
  initContainers:
   - name: plugin-setup
     image: kong:2.7
     command:
       [
         "sh",
         "-c",
         "cd /home/kong && luarocks download kong-plugin-acp 1.0.0-1 && luarocks unpack kong-plugin-acp-* && mv kong-plugin-acp-*/lua/kong/plugins/acp/* /opt/acp",
       ]
     volumeMounts:
       - name: "custom-kong-plugin-acp"
         mountPath: "/opt/acp"
  userDefinedVolumes:
   - name: "custom-kong-plugin-acp"
     emptyDir: {}
  userDefinedVolumeMounts:
   - name: "custom-kong-plugin-acp"
     mountPath: "/usr/local/share/lua/5.1/kong/plugins/acp"

    When ready, save your file (you can also the path in a variable, for example ${KONG_CONFIG}).

  2. Run the command below to create a Kong Gateway with the following parameters:

    • Service name: kong
    • Namespace: kong-system
    • Configuration: - path to your configuration file (you can also save it in a variable, for example ${KONG_CONFIG})
    helm repo add kong https://charts.konghq.com
helm repo update
helm upgrade kong kong/kong \
   --namespace kong-system \
   --values ${KONG_CONFIG} \
   --timeout 5m \
   --create-namespace \
   --install

The configuration file bootstraps a Kong Gateway. As a result, the Kong Gateway is deployed together with the ACP Luarocks plugin.

Create Kong Authorizer in Cloudentity

Before deploying Kong Authorizer, you must create it in Cloudentity.

  1. In your Cloudentity tenant, go to the workspace of your choice.

  2. Select Enforcement > Authorizers > CREATE GATEWAY > Kong.

  3. Provide a name and a description for your Kong Authorizer.

  4. Optionally, enable the Create and bind services automatically check box.

    Tip

    When enabled, all services protected by your Kong Authorizer instance are discovered and added to the Cloudentity service list automatically when the Kong authorizer is connected to Cloudentity. Otherwise, you need to add them manually.

Now, Kong Authorizer is created as a client in Cloudentity. Copy the Client ID, Client Secret and Issuer URL as you will need it later to deploy Kong Authorizer.

Deploy Kong Authorizer with Helm Charts

Cloudentity provides a dedicated Helm Chart for deploying the Kong Authorizer.

  1. Run the command below to create a Kong Authorizer service with the following parameters:

    • Service name: kong-authorizer

    • Namespace: acp-kong-authorizer

    • ${CLIENT_ID}, ${CLIENT_SECRET}, ${ISSUER_URL} - Authorizer Client ID, Client Secret, and Issuer URL which you can retrieve from Cloudentity having created the authorizer.

      The issuerURL argument should point to the issuer URL of your Kong Authorizer client application created within the System workspace of your tenant. You can find the issuer URL in the Settings view for your authorizer. If you are using a vanity domain for your Cloudentity tenant and it is impossible to retrieve the tenant’s and server’s identifier from the URL, provide values for the tenantID and serverID parameters in addition to issuerURL.

    • ${KONG_ADMIN_URL} - an address where the Kong Admin API is listening (it’s on the 8001 port by default)

    Example without vanity domains:

    helm upgrade --install kong-authorizer acp/kong-authorizer \
  --set clientCredentials.clientID=${CLIENT_ID} \
  --set clientCredentials.clientSecret=${CLIENT_SECRET} \
  --set issuerURL=${ISSUER_URL} \
  --set kongAdminURL=${KONG_ADMIN_URL} \
  --namespace acp-kong-authorizer \
  --create-namespace

    Example with vanity domains:

    helm upgrade --install kong-authorizer acp/kong-authorizer \
  --set clientCredentials.clientID=${CLIENT_ID} \
  --set clientCredentials.clientSecret=${CLIENT_SECRET} \
  --set issuerURL=${VANITY_ISSUER_URL} \
  --set tenantID=${TENANT_ID} \
  --set serverID=${SERVER_ID} \
  --namespace acp-kong-authorizer \
  --create-namespace

Customize Kong Authorizer

You can add the following custom configuration to the Kong Authorizer:

  • Cloudentity server certificates via httpServer.cert and httpServer.certKey.

  • Disabling the certificate verification (for example when you want to use self-signed certificates for testing purposes) via the HTTP_CLIENT_INSECURE_SKIP_VERIFY: true flag

  • If you want to import services to Cloudentity declaratively, you can disable the automatic service discovery via the discovery.enabled flag.

  • If you’re customizing Kong Authorizer, it makes sense to add the Client ID, Client Secret, Issuer URL and Kong Admin URL to the file as well, to keep the configuration in one place. If these parameters are not in the file, they must be set when deploying the authorizer.

A sample file with all the configured parameters can look as follows:

clientCredentials:
  clientID: "kong_authorizer_gateway_client"
  clientSecret: "m5wxaxmfcthrgo0ykw9hv8oda6ua09d1"
discovery:
  enabled: false
issuerURL: "https://acp.acp-system:8443/system/system"
kongAdminURL: "http://kong-kong-admin.kong-system:8001"
extraEnvVars:
  HTTP_CLIENT_INSECURE_SKIP_VERIFY: true
httpServer:
  cert: |
    -----BEGIN CERTIFICATE-----
    .........................
    -----END CERTIFICATE-----    
  certKey: |
    -----BEGIN RSA PRIVATE KEY-----
    .............................
    -----END RSA PRIVATE KEY-----

When ready, save your file (you can also export the file path in a variable, for example ${KONG_AUTHORIZER_CONFIG}) and deploy Kong Authorizer from the file.

helm upgrade --install kong-authorizer acp/kong-authorizer \
  --namespace acp-kong-authorizer \
  --values ${KONG_AUTHORIZER_CONFIG} \
  --create-namespace

Declarative Configuration for DB-less Setup

If your Kong Gateway is running without a database, you can use declarative configuration for your service to assign the acp plugin to your service as shown below (note that sample routes and services are also declared):

services:
- name: httpbin-service
   url: https://httpbin.org
   routes:
   - name: anything
      hosts: [ "httpbin.org" ]
      paths: [ "/anything" ]
      methods: [ "GET", "PATCH", "PUT", "POST", "DELETE" ]
      strip_path: false
   plugins:
   - name: acp
      config:
      api_group_id: httpbin-service
      auth_url: https://kong-authorizer:9003/authorize

Apply a sample policy

  1. In Cloudentity, create a policy.

  2. Go to Enforcement > APIs > AUTHORIZATION.

  3. Select a service protected by the Kong Authorizer and any API with authorization status Unrestricted.

  4. In the Edit API popup window, select Policy from the list and click Update to proceed.

Result

You have successfully assigned a policy to your API.

Test Kong Gateway integration

To test if your integration was successful and that your APIs are protected, you can, for example, create a simple Cloudentity or REGO policy that will always pass. Call your protected endpoint (below, it’s /anything) and check if the response is successful.

Connected APIs

You can see which APIs are protected by your Kong authorizer by checking under Enforcement > Authorizers > YOUR_KONG_AUTHORIZER > APIs.

curl -i --request GET http://localhost:8000/anything

If the request is succesful, change your policy so that it blocks APIs. The next request to your protected endpoint should be blocked with the unauthorized access error.

Configure Kong Authorizer

The Kong Authorizer can be configured with a file in YAML format, or via environment variables. To generate a template configuration file that is populated with default settings, you can use a Docker image and pipe the output to a configuration file:

docker run --rm docker.cloudentity.io/kong-authorizer reference > reference_config.yaml

You can use the reference configuration as a basis for your customization. You can omit settings for which the default configuration is satisfactory, specifying only the required values, which are the client ID, client secret, issuer URL, and Kong admin URL parameters.

ACP_CLIENT_ID: {your_client_id}
ACP_CLIENT_SECRET: {your_client_secret}
ACP_ISSUER_URL: https://{tid}.us.authz.stage.cloudentity.io/{tid}/system
KONG_ADMIN_URL: http://kong-acp:8001

Environment variables can also be used to set these configuration values. The environment variable’s name are the uppercase version of the YAML name. For example, in the docker-compose.yml that you downloaded, you can set the ACP_CLIENT_ID via the environment variable ACP_CLIENT_ID:

    environment:
      - ACP_CLIENT_ID=${CLIENT_ID}
      - ACP_CLIENT_SECRET=${CLIENT_SECRET}
      - ACP_ISSUER_URL=${ISSUER_URL}
      - ACP_HTTP_CLIENT_INSECURE_SKIP_VERIFY=TRUE
      - KONG_ADMIN_URL=${KONG_ADMIN_URL}
      - KONG_HTTP_CLIENT_INSECURE_SKIP_VERIFY=TRUE
      - SERVER_LISTENER_PORT=9003

Tip

Note that nested YAML settings can be accessed by joining uppercased names with underscores, as shown in the example above, where the SERVER_LISTENER_PORT=9003 parameter is set.

To run the kong authorizer with a configuration file, use the --config option to specify the YAML file with your configuration. For example, assuming that you have created a kong_config.yaml file in your current directory your docker run command would look like the following:

docker run --rm --volume `pwd`:/config:ro docker.cloudentity.io/kong-authorizer --config /config/kong_config.yaml

Authenticating to the Kong Admin API

The Kong Authorizer can authenticate to the Kong Admin API in one of three ways:

  • RBAC User Token
  • HTTP Basic Authentication
  • OAUTH2 Authentication

RBAC Authentication

To authenticate when the Kong Admin API is secured by RBAC, supply the RBAC user token via the environment variable KONG_ADMIN_TOKEN, or the YAML field kong.admin_token:

Licensed Enterprise users only

RBAC is only available for licensed Kong Gateway users. It’s not possible to enable RBAC on a free Kong Enterprise version or the Open Source version.

kong:
  admin_url: https://kong:8444
  admin_token: vajeOlkbsn0q0VD9qw9B3nHYOErgY7b8

Basic Authentication

To authenticate when the Kong Admin API is secured by the Kong basic-auth plugin, specify the environment variables KONG_ADMIN_USERNAME and KONG_ADMIN_PASSSWORD, or specify them via the YAML configuration:

kong:
  admin_url: https://kong:8443/admin-api
  admin_username: kong-admin
  admin_password: sesame

As a result, when the authorizer tries to access the Kong API without credentials, the request fails.

{
    "message": "Unauthorized"
}

OAuth2 Authentication

To authenticate when the Kong Admin API is secured by the Kong oauth2 plugin, specify the environment variables KONG_ADMIN_CLIENT_ID, KONG_ADMIN_CLIENT_SECRET, and KONG_ADMIN_ISSUER_URL, or specify them via the YAML configuration:

kong:
  admin_url: https://kong:8443/admin-api
  admin_client_id: kong-authorizer-id
  admin_client_secret: kong-authorizer-secret
  admin_issuer_url: https://kong:8443/admin-api

As a result, when the authorizer tries to access the Kong API without the access token, the request fails.

{"error":"invalid_request","error_description":"The access token is missing"}

Configuration Reference

 # acp
acp:
    reload_interval: 1m0s # reload interval
    reload_timeout: 30s # reload configuration timeout
    issuer_url: https://localhost:8443/sample/system # issuer url
    client_id: bqesdrc4m4co2s81mpu0 # client id
    client_secret: LH6mAb6PNljvjYMIF-A5RP2bElA5a5bnQah8sG0fsLA # client secret
    tenant_id: "" # tenant id
    server_id: "" # server id
# http client
http_client:
    timeout: 10s # http client timeout
    retry_wait_min: 0s # minimum time to wait between retries
    retry_wait_max: 0s # maximum time to wait between retries
    retry_max: 0 # maximum number of retries
    root_ca: "" # root ca that this client should trust (defaults to system root ca)
    insecure_skip_verify: false # disable cert verification
    disable_follow_redirects: false # disable follow redirects
    disable_retry: true # disable retry
# metrics
metrics:
    enabled: false # enable metrics endpoint
    port: 9000 # metrics endpoint port
# analytics
analytics:
    enabled: true # when enabled, events are sent to audit log
    # event format
    event_format:
        include_policy_output: false # when enabled, policy evaluation output is sent to audit log
    # sampling
    sampling:
        probability: 1 # Probability of an event to be published (0.0-1.0)
        batch_inverval: 1s # Max duration to wait for a batch to publish
        batch_limit: 100 # Max number of events in a batch
        limit: 5 # Max number of batches per second to be published
        timeout: 5s # Timeout for a single batch to send
        workers: 8 # Number of sending workers
# cache
cache:
    ttl: 10s # ttl
    max_size: 100 # max size
# logging config
logging:
    level: info # log level severity
# token echange config
token_exchange:
    enabled: false # enable token exchange
    # cache
    cache:
        ttl: 1m0s # ttl
        max_size: 1000 # max size
    # inject config (supported only for istio authorizer)
    inject:
        mode: "" # Defines what token should be sent to the target service when token is exchanged
        # headers config
        headers:
            exchanged_token: "" # Defines the name of the header that contains an exchanged token.
            original_token: "" # Defines the name of the header that contains an original token.
            strip_bearer: false # Allows to strip the bearer prefix in headers
# enforcement config
enforcement:
    allow_unknown: false # allow requests with no matching rule
# discovery config
discovery:
    enabled: true # when true, API discovery is enabled
    timeout: 10s # discovery process timeout
    interval: 30s # how often discovery is performed
# http server
http_server:
    port: 9003 # http port
    dangerous_disable_tls: false # diables TLS
    # certificate configuration
    certificate:
        password: "" # key passphrase
        cert_path: "" # path to the certificate PEM file
        key_path: "" # path to the key PEM file
        cert: "" # base64 encoded cert PEM
        key: "" # base64 encoded key PEM
        generated_key_type: ecdsa # type for generated key if cert and key are not provided (rsa or ecda)
    client_auth_type: 0 # client auth type
# kong
kong:
    admin_url: "" # kong admin url indicates the Kong Admin API
    admin_token: "" # kong admin token for RBAC authentication to Kong Admin API
    admin_username: "" # kong admin username for Basic Auth to Kong Admin API
    admin_password: "" # kong admin password for Basic Auth to Kong Admin API
    admin_client_id: "" # kong admin client ID for OAuth2 authentication to the Kong Admin API
    admin_client_secret: "" # kong admin client secret for OAuth2 authentication to the Kong Admin API
    admin_issuer_url: "" # kong admin issuer url for OAuth2 authentication to the Kong Admin API
    # http client used to access the Kong Admin API
    http_client:
        timeout: 0s # http client timeout
        retry_wait_min: 0s # minimum time to wait between retries
        retry_wait_max: 0s # maximum time to wait between retries
        retry_max: 0 # maximum number of retries
        root_ca: "" # root ca that this client should trust (defaults to system root ca)
        insecure_skip_verify: true # disable cert verification
        disable_follow_redirects: false # disable follow redirects
        disable_retry: false # disable retry
Updated: Nov 9, 2022