CVE-2020-11710: Other (NVD-CWE-Other)
value: An issue was discovered in docker-kong (for Kong) through 2.0.3. The admin API port may be accessible on interfaces other than 127.0.0.1. NOTE: The vendor argue that this CVE is not a vulnerability because it has an inaccurate bug scope and patch links. “1) Inaccurate Bug Scope - The issue scope was on Kong's docker-compose template, and not Kong's docker image itself. In reality, this issue is not associated with any version of the Kong gateway. As such, the description stating ‘An issue was discovered in docker-kong (for Kong) through 2.0.3.’ is incorrect. This issue only occurs if a user decided to spin up Kong via docker-compose without following the security documentation. The docker-compose template is meant for users to quickly get started with Kong, and is meant for development purposes only. 2) Incorrect Patch Links - The CVE currently points to a documentation improvement as a “Patch” link: https://github.com/Kong/docs.konghq.com/commit/d693827c32144943a2f45abc017c1321b33ff611.This link actually points to an improvement Kong Inc made for fool-proofing. However, instructions for how to protect the admin API were already well-documented here: https://docs.konghq.com/2.0.x/secure-admin-api/#network-layer-access-restrictions , which was first published back in 2017 (as shown in this commit: https://github.com/Kong/docs.konghq.com/commit/e99cf875d875dd84fdb751079ac37882c9972949) Lastly, the hyperlink to https://github.com/Kong/kong (an unrelated Github Repo to this issue) on the Hyperlink list does not include any meaningful information on this topic.
CWE description: NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
CVSS v3 base score: 9.8
Published: 2020-04-12T17:15Z
Repository: https://github.com/Kong/docs.konghq.com
Language: Markdown
Files changed: app/_data/docs_nav_0.10.x.yml, app/docs/0.10.x/admin-api.md, app/docs/0.10.x/secure-admin-api.md
Commit date: 2017-06-02 09:08:02 -0700
Commit message: docs(admin-api) securing the admin api

Diff: diff --git a/app/_data/docs_nav_0.10.x.yml b/app/_data/docs_nav_0.10.x.yml
index 3aa7e42b..125a55df 100644
--- a/app/_data/docs_nav_0.10.x.yml
+++ b/app/_data/docs_nav_0.10.x.yml
@@ -39,10 +39,13 @@
       url: /network
 
     - text: Public Lua API reference
       url: /lua-reference/
 
+    - text: Securing the Admin API
+      url: /secure-admin-api
+
     - text: Plugin Development Guide
       url: /plugin-development
       items:
         - text: Introduction
           url: /plugin-development
diff --git a/app/docs/0.10.x/admin-api.md b/app/docs/0.10.x/admin-api.md
index f2aba4b1..5958eb9c 100644
--- a/app/docs/0.10.x/admin-api.md
+++ b/app/docs/0.10.x/admin-api.md
@@ -66,10 +66,15 @@ Requests to the Admin API can be sent to any node in the cluster, and Kong will
 keep the configuration consistent across all nodes.
 
 - `8001` is the default port on which the Admin API listens.
 - `8444` is the default port for HTTPS traffic to the Admin API.
 
+This API is designed for internal use and provides full control over Kong, so
+care should be taken when setting up Kong environments to avoid undue public
+exposure of this API. See [this document][secure-admin-api] for a discussion
+of methods to secure the Admin API.
+
 ## Supported Content Types
 
 The Admin API accepts 2 content types on every endpoint:
 
 - **application/x-www-form-urlencoded**
@@ -1876,5 +1881,6 @@ Attributes | Description
 HTTP 204 No Content
 ```
 
 [clustering]: /docs/{{page.kong_version}}/clustering
 [cli]: /docs/{{page.kong_version}}/cli
+[secure-admin-api]: /docs/{{page.kong_version}}/secure-admin-api
diff --git a/app/docs/0.10.x/secure-admin-api.md b/app/docs/0.10.x/secure-admin-api.md
new file mode 100644
index 00000000..e41f5dbd
--- /dev/null
+++ b/app/docs/0.10.x/secure-admin-api.md
@@ -0,0 +1,142 @@
+---
+title: Securing the Admin API
+---
+
+# Overview
+
+Kong's Admin API provides a RESTful interface for administration and
+configuration of APIs, plugins, consumers, and credentials. Because this
+API allows full control of Kong, it is important to secure this API against
+unwanted access. This document describes a few possible approaches to securing
+the Admin API.
+
+## Table of Contents
+
+- [Network Layer Access Restrictions](#network-layer-access-restrictions)
+  - [Reduce Listening Footprint](#reduce-listening-footprint)
+  - [Layer 3/4 Network Controls](#layer-34-network-controls)
+- [Kong API Loopback](#kong-api-loopback)
+- [Custom Nginx Configuration](#custom-nginx-configuration)
+
+## Network Layer Access Restrictions
+
+### Reduce Listening Footprint
+
+By default, Kong will accept requests for both the public-facing entrypoint, and
+the Admin API, on `0.0.0.0`, which will bind to all available interfaces on the
+host. Reducing this exposure footprint by limiting the interfaces by which the
+Admin API can be accessed is a foundational step. This setting can be adjusted
+via the `admin_listen` Kong configuration directive. For example:
+
+`admin_listen 127.0.0.1:8001`
+
+This will define the Nginx `listen` directive used by Kong to the prescribed
+value, instructing Kong to only respond to requests received on the localhost
+interface.
+
+[Back to TOC](#table-of-contents)
+
+### Layer 3/4 Network Controls
+
+In cases where the Admin API must be exposed beyond a localhost interface,
+network security best practices dictate that network-layer access be restricted
+as much as possible. Consider an environment in which Kong listens on a private
+network interface, but should only be accessed by a small subset of an IP range.
+In such a case, host-based firewalls (e.g. iptables) are useful in limiting
+input traffic ranges. For example:
+
+
+```bash
+# assume that Kong is listening on the address defined below, as defined as a
+# /24 CIDR block, and only a select few hosts in this range should have access
+
+$ grep admin_listen /etc/kong/kong.conf
+admin_listen 10.10.10.3
+
+# explicitly allow TCP packets on port 8001 from the Kong node itself
+# this is not necessary if Admin API requests are not sent from the node
+$ iptables -A INPUT -s 10.10.10.3 -m tcp -p tcp --dport 8001 -j ACCEPT
+
+# explicitly allow TCP packets on port 8001 from the following addresses
+$ iptables -A INPUT -s 10.10.10.4 -m tcp -p tcp --dport 8001 -j ACCEPT
+$ iptables -A INPUT -s 10.10.10.5 -m tcp -p tcp --dport 8001 -j ACCEPT
+
+# drop all TCP packets on port 8001 not in the above IP list
+$ iptables -A INPUT -m tcp -p tcp --dport 8001 -j DROP
+
+```
+
+Additional controls, such as similar ACLs applied at a network device level, are
+encouraged, but fall outside the scope of this document.
+
+[Back to TOC](#table-of-contents)
+
+## Kong API Loopback
+
+Kong's routing design allows it to serve as a proxy for the Admin API itself. In
+this manner, Kong itself can be used to provide fine-grained access control to
+the Admin API. Such an environment requires bootstrapping a new API that defines
+the `admin_listen` address as the API's `upstream_url`. For example:
+
+```bash
+# assume that Kong has defined admin_listen as 127.0.0.1:8001, and we want to
+# reach the Admin API via the url `/admin-api`
+
+$ curl http://localhost:8001/apis \
+  --data name=admin-api \
+  --data uris=/admin-api \
+  --data upstream_url=http://localhost:8001
+
+# we can now transparently reach the Admin API through the proxy server
+$ curl localhost:8000/admin-api/apis
+{  
+   "data":[  
+      {  
+         "uris":[  
+            "\/admin-api"
+         ],
+         "id":"653b21bd-4d81-4573-ba00-177cc0108dec",
+         "upstream_read_timeout":60000,
+         "preserve_host":false,
+         "created_at":1496351805000,
+         "upstream_connect_timeout":60000,
+         "upstream_url":"http:\/\/localhost:8001",
+         "strip_uri":true,
+         "https_only":false,
+         "name":"admin-api",
+         "http_if_terminated":true,
+         "upstream_send_timeout":60000,
+         "retries":5
+      }
+   ],
+   "total":1
+}
+```
+
+From here, simply apply desired Kong-specific security controls (such as
+[basic][basic-auth] or [key authentication][key-auth],
+[IP restrictions][ip-restriction], or [access control lists][acl]) as you would
+normally to any other Kong API.
+
+[Back to TOC](#table-of-contents)
+
+## Custom Nginx Configuration
+
+Kong is tightly coupled with Nginx as an HTTP daemon, and can thus be integrated
+into environments with custom Nginx configurations. In this manner, use cases
+with complex security/access control requirements can use the full power of
+Nginx/OpenResty to build server/location blocks to house the Admin API as
+necessary. This allows such environments to leverage native Nginx authorization
+and authentication mechanisms, ACL modules, etc., in addition to providing the
+OpenResty environment on which custom/complex security controls can be built.
+
+For more information on integrating Kong into custom Nginx configurations, see
+[Custom Nginx configuration & embedding Kong][custom-configuration].
+
+[Back to TOC](#table-of-contents)
+
+[acl]: /plugins/acl
+[basic-auth]: /plugins/basic-authentication/
+[custom-configuration]: /docs/{{page.kong_version}}/configuration/#custom-nginx-configuration
+[ip-restriction]: /plugins/ip-restriction
+[key-auth]: /plugins/key-authentication

Fixed code:     - text: Securing the Admin API
      url: /secure-admin-api

This API is designed for internal use and provides full control over Kong, so
care should be taken when setting up Kong environments to avoid undue public
exposure of this API. See [this document][secure-admin-api] for a discussion
of methods to secure the Admin API.

[secure-admin-api]: /docs/{{page.kong_version}}/secure-admin-api
---
title: Securing the Admin API
---

# Overview

Kong's Admin API provides a RESTful interface for administration and
configuration of APIs, plugins, consumers, and credentials. Because this
API allows full control of Kong, it is important to secure this API against
unwanted access. This document describes a few possible approaches to securing
the Admin API.

## Table of Contents

- [Network Layer Access Restrictions](#network-layer-access-restrictions)
  - [Reduce Listening Footprint](#reduce-listening-footprint)
  - [Layer 3/4 Network Controls](#layer-34-network-controls)
- [Kong API Loopback](#kong-api-loopback)
- [Custom Nginx Configuration](#custom-nginx-configuration)

## Network Layer Access Restrictions

### Reduce Listening Footprint

By default, Kong will accept requests for both the public-facing entrypoint, and
the Admin API, on `0.0.0.0`, which will bind to all available interfaces on the
host. Reducing this exposure footprint by limiting the interfaces by which the
Admin API can be accessed is a foundational step. This setting can be adjusted
via the `admin_listen` Kong configuration directive. For example:

`admin_listen 127.0.0.1:8001`

This will define the Nginx `listen` directive used by Kong to the prescribed
value, instructing Kong to only respond to requests received on the localhost
interface.

[Back to TOC](#table-of-contents)

### Layer 3/4 Network Controls

In cases where the Admin API must be exposed beyond a localhost interface,
network security best practices dictate that network-layer access be restricted
as much as possible. Consider an environment in which Kong listens on a private
network interface, but should only be accessed by a small subset of an IP range.
In such a case, host-based firewalls (e.g. iptables) are useful in limiting
input traffic ranges. For example:


```bash
# assume that Kong is listening on the address defined below, as defined as a
# /24 CIDR block, and only a select few hosts in this range should have access

$ grep admin_listen /etc/kong/kong.conf
admin_listen 10.10.10.3

# explicitly allow TCP packets on port 8001 from the Kong node itself
# this is not necessary if Admin API requests are not sent from the node
$ iptables -A INPUT -s 10.10.10.3 -m tcp -p tcp --dport 8001 -j ACCEPT

# explicitly allow TCP packets on port 8001 from the following addresses
$ iptables -A INPUT -s 10.10.10.4 -m tcp -p tcp --dport 8001 -j ACCEPT
$ iptables -A INPUT -s 10.10.10.5 -m tcp -p tcp --dport 8001 -j ACCEPT

# drop all TCP packets on port 8001 not in the above IP list
$ iptables -A INPUT -m tcp -p tcp --dport 8001 -j DROP

```

Additional controls, such as similar ACLs applied at a network device level, are
encouraged, but fall outside the scope of this document.

[Back to TOC](#table-of-contents)

## Kong API Loopback

Kong's routing design allows it to serve as a proxy for the Admin API itself. In
this manner, Kong itself can be used to provide fine-grained access control to
the Admin API. Such an environment requires bootstrapping a new API that defines
the `admin_listen` address as the API's `upstream_url`. For example:

```bash
# assume that Kong has defined admin_listen as 127.0.0.1:8001, and we want to
# reach the Admin API via the url `/admin-api`

$ curl http://localhost:8001/apis \
  --data name=admin-api \
  --data uris=/admin-api \
  --data upstream_url=http://localhost:8001

# we can now transparently reach the Admin API through the proxy server
$ curl localhost:8000/admin-api/apis
{  
   "data":[  
      {  
         "uris":[  
            "\/admin-api"
         ],
         "id":"653b21bd-4d81-4573-ba00-177cc0108dec",
         "upstream_read_timeout":60000,
         "preserve_host":false,
         "created_at":1496351805000,
         "upstream_connect_timeout":60000,
         "upstream_url":"http:\/\/localhost:8001",
         "strip_uri":true,
         "https_only":false,
         "name":"admin-api",
         "http_if_terminated":true,
         "upstream_send_timeout":60000,
         "retries":5
      }
   ],
   "total":1
}
```

From here, simply apply desired Kong-specific security controls (such as
[basic][basic-auth] or [key authentication][key-auth],
[IP restrictions][ip-restriction], or [access control lists][acl]) as you would
normally to any other Kong API.

[Back to TOC](#table-of-contents)

## Custom Nginx Configuration

Kong is tightly coupled with Nginx as an HTTP daemon, and can thus be integrated
into environments with custom Nginx configurations. In this manner, use cases
with complex security/access control requirements can use the full power of
Nginx/OpenResty to build server/location blocks to house the Admin API as
necessary. This allows such environments to leverage native Nginx authorization
and authentication mechanisms, ACL modules, etc., in addition to providing the
OpenResty environment on which custom/complex security controls can be built.

For more information on integrating Kong into custom Nginx configurations, see
[Custom Nginx configuration & embedding Kong][custom-configuration].

[Back to TOC](#table-of-contents)

[acl]: /plugins/acl
[basic-auth]: /plugins/basic-authentication/
[custom-configuration]: /docs/{{page.kong_version}}/configuration/#custom-nginx-configuration
[ip-restriction]: /plugins/ip-restriction
[key-auth]: /plugins/key-authentication