1 introduction

1.1 Why is an API Gateway needed?

When using a singleton application architecture, the client (Web or mobile) makes a REST call to the back-end application to retrieve the data. The load balancer routes requests to one of N identical application instances. The application then queries the various database tables and returns the responses to the client. In the microservice architecture, a single application is divided into multiple microservices. If all the microservices are directly exposed to the outside world, various security problems are bound to occur.

Clients can directly send requests to each microservice, and the main problems are as follows:

  • The fine granularity of client requirements and exposure of each microserviceAPIDon’t match.
  • Some services use protocols that are not Web friendly. May be usedThriftbinaryRPC, may also be usedAMQPMessaging protocol.
  • Microservices are difficult to refactor. If two services are merged, or a service is split into two or more services, this kind of refactoring becomes very difficult.

The direct exposure of each service on the server side to the client invocation is bound to cause various problems. At the same time, the individual services on the server side are poorly extensible and scalable. The API gateway is a fundamental component in the microservices architecture, located below the access layer and above the business services layer. These functions are suitable for implementation in the API gateway as described earlier.

1.2 What is Kong?

When we decide to micro-service the application, the question of how the application client interacts with the micro-service comes along. After all, the increase in the number of services directly leads to the difficulty of deployment authorization, load balancing, communication management, analysis and change.

The API GATEWAY provides access restriction, security, traffic control, analysis monitoring, logging, request forwarding, compositing, and protocol transformation capabilities that free developers to focus on specific logic code. Instead of spending time figuring out how to link apps to other microservices.

1.3 Why Use Kong?

While there is more than one API gateway offering a similar approach, Kong focuses on the following four traditional pain points:

Pain points instructions
Repeat more Common functionality is repeated across multiple microservices, such as authentication or logging related common modules
The giant petrochemical Individual services still tend to turn into tail-big boulder apps
influence The impact is so large that it is difficult to extend functionality without affecting other services
Low efficiency Low productivity due to system limitations

1.4 Basic architecture of Kong

Kong is Mashape open source high-performance high availability API gateway and API service management, a high availability service gateway written based on the Nginx_Lua module. Since Kong is based on Nginx, it can be extended to multiple Kong servers. Requests are evenly distributed to each Server through pre-configured load balancing configuration to cope with a large number of network requests.

Kong has three main components:

  • Kong ServerBased on:NginxTo receive API requests.
  • Apache Cassandra/PostgreSQL: Used to store operational data.
  • Kong dashboardThe UI management tool is officially recommended. Of course, it can also be usedrestfullAdmin API.

Kong Dashboard supported versions

Kong uses a plug-in mechanism for functionality customization, where a set of plug-ins (which can be 0 or N) is executed during the lifecycle of the API request response cycle. The plug-in is written using Lua, and its basic functions include HTTP basic authentication, key authentication, CROSS-origin Resource Sharing (CORS), TCP, UDP, file logging, API request flow limiting, request forwarding, and Nginx monitoring.

2 the installation

2.1 Local Deployment

2.1.1 Configuring the YUM Repository

sudo yum install -y wget
wget https://bintray.com/kong/kong-rpm/rpm -O bintray-kong-kong-rpm.repo
export major_version=`grep -oE '[0-9]+\.[0-9]+' /etc/redhat-release | cut -d "." -f1`
sed -i -e 's/baseurl.*/&\/centos\/'$major_version''/ bintray-kong-kong-rpm.repo
sudo mv bintray-kong-kong-rpm.repo /etc/yum.repos.d/
sudo yum install -y kong
Copy the code

2.1.2 to install PostgreSQL

yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm yum  install -y postgresql11 postgresql11-server /usr/pgsql-11/bin/postgresql-11-setup initdb systemctl enable postgresql-11 Systemctl start postgresql-11 # PSQL sudo su postgres PSQL # set password postgres=# \password Enter new password: Postgres =# # CREATE database CREATE USER kong with password 'kong'; CREATE DATABASE kong OWNER kong; grant all privileges on database kong to kong; # modified security configuration vim/var/lib/PGSQL/data / 11 / pg_hba. Conf # # to modify the bottom lines "local" is for Unix domain socket connections only local all All md5 # IPv4 local connections: host all all 127.0.0.1/32 MD5 # IPv6 local connections: host all all ::1/128 md5 # Allow replication connections from localhost, By a user with the # replication privilege. Local replication all MD5 host replication all 127.0.0.1/32 ident host Replication all ::1/128 ident # restart Postgresql systemctl restart postgresqL-11Copy the code

2.1.3 configuration Kong

# configuration in advance is needed here kong configuration file, / etc/default/kong kong. Conf. Default cp/etc/kong kong. Conf. The default/etc/kong kong. Conf # modify the database configuration inside, Write the information such as user, password, database, port vim/etc/kong kong. Conf/root @ master / # egrep - v "^ # | $| ^ ^ [[: space:]] + #"/etc/kong kong. Conf database Determines which effects of postgres or Cassandra pg_host = 127.0.0.1 # Host of the postgres server 5432 # Port of the Postgres server. pg_timeout = 5000 # Defines the timeout (in ms), for connecting, pg_user = kong # Postgres user. pg_password = kong # Postgres user's password. pg_database = kong # The database name to  connect to.Copy the code

2.1.4 perform Migration

[root@master ~]# kong migrations bootstrap -c /etc/kong/kong.conf
Bootstrapping database...
migrating core on database 'kong'...
core migrated up to: 000_base (executed)
core migrated up to: 001_14_to_15 (executed)
core migrated up to: 002_15_to_1 (executed)
core migrated up to: 003_100_to_110 (executed)
core migrated up to: 004_110_to_120 (executed)
core migrated up to: 005_120_to_130 (executed)
core migrated up to: 006_130_to_140 (executed)
core migrated up to: 007_140_to_200 (executed)
migrating hmac-auth on database 'kong'...
hmac-auth migrated up to: 000_base_hmac_auth (executed)
hmac-auth migrated up to: 001_14_to_15 (executed)
hmac-auth migrated up to: 002_130_to_140 (executed)
migrating oauth2 on database 'kong'...
oauth2 migrated up to: 000_base_oauth2 (executed)
oauth2 migrated up to: 001_14_to_15 (executed)
oauth2 migrated up to: 002_15_to_10 (executed)
oauth2 migrated up to: 003_130_to_140 (executed)
migrating jwt on database 'kong'...
jwt migrated up to: 000_base_jwt (executed)
jwt migrated up to: 001_14_to_15 (executed)
jwt migrated up to: 002_130_to_140 (executed)
migrating basic-auth on database 'kong'...
basic-auth migrated up to: 000_base_basic_auth (executed)
basic-auth migrated up to: 001_14_to_15 (executed)
basic-auth migrated up to: 002_130_to_140 (executed)
migrating key-auth on database 'kong'...
key-auth migrated up to: 000_base_key_auth (executed)
key-auth migrated up to: 001_14_to_15 (executed)
key-auth migrated up to: 002_130_to_140 (executed)
migrating acl on database 'kong'...
acl migrated up to: 000_base_acl (executed)
acl migrated up to: 001_14_to_15 (executed)
acl migrated up to: 002_130_to_140 (executed)
migrating session on database 'kong'...
session migrated up to: 000_base_session (executed)
migrating response-ratelimiting on database 'kong'...
response-ratelimiting migrated up to: 000_base_response_rate_limiting (executed)
response-ratelimiting migrated up to: 001_14_to_15 (executed)
response-ratelimiting migrated up to: 002_15_to_10 (executed)
migrating rate-limiting on database 'kong'...
rate-limiting migrated up to: 000_base_rate_limiting (executed)
rate-limiting migrated up to: 001_14_to_15 (executed)
rate-limiting migrated up to: 002_15_to_10 (executed)
rate-limiting migrated up to: 003_10_to_112 (executed)
35 migrations processed
35 executed
Database is up-to-date
Copy the code

2.1.5 start

Conf database=off [root@master ~]# kong start -c /etc/kong/kong.conf kong started [root@master ~]# kong health nginx....... running Kong is healthy at /usr/local/kongCopy the code

2.1.6 Test Use

  • Create a Service

As we explained in the terminology section, a service is an abstraction of an upstream service, which can be an application or a concrete interface. Kong provides the management interface. We can create the management interface directly by requesting 8001 or through the installed management interface. The effect is the same.

Curl - I - X POST \ \ - url http://139.196.189.67:8001/services/ - data 'name = baidu - service \ - data 'url=https://www.baidu.com/'Copy the code
  • Create a route

Once the service is created, we need to create a concrete API route. Routing is a forwarding rule for requests, which are forwarded according to Hostname and PATH.

Curl - ik - X POST \ \ - url http://139.196.189.67:8001/services/baidu-service/routes - data 'hosts [] = baidu.com' \ - data 'paths[]=/api/baidu'Copy the code
  • Access to the test
Curl http://139.196.189.67:8000/api/baidu -- - k header 'Host: baidu.com'Copy the code

2.2 Container Deployment

2.2.1 deployment PostgreSQL

2.2.1.1 Creating a Network

docker network create kong-net
Copy the code

2.2.1.2 Creating a Data Volume

docker volume create pgsql 
docker volume create kong
Copy the code

2.2.1.3 deployment Postgres:

docker run -it --name kong-database -v pgsql:/var/lib/postgresql/data --network=kong-net -p 5432:5432 -e "POSTGRES_PASSWORD=pgsql" -d postgres:9.6
Copy the code

2.2.1.4 Adding database Information

docker exec -it kong-database bash 
> su postgres 
> psql -h localhost --password 
# Input password
Create an account and database using the following statement
CREATE USER kong password 'kong'; 
CREATE DATABASE kong OWNER kong; 
grant all privileges on database kong to kong;   

CREATE USER konga password 'konga'; 
CREATE DATABASE konga OWNER konga; 
grant all privileges on database konga to konga;
Copy the code

2.2.2 deployment Kong

2.2.2.1 Preparing Data

docker run --rm --network=kong-net -e "KONG_DATABASE=postgres" -e "KONG_PG_HOST=kong-database" -e "KONG_PG_USER=kong" -e "KONG_PG_PASSWORD=kong" -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" kong:latest kong migrations bootstrap
Copy the code

2.2.2.2 start Kong

docker run -d --name kong --network=kong-net -e "KONG_DATABASE=postgres" -e "KONG_PG_HOST=kong-database" -e "KONG_PG_USER=kong" -e "KONG_PG_PASSWORD=kong" -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" -e "KONG_PROXY_ERROR_LOG=/dev/stderr" -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" -e "KONG_ADMIN_LISTEN = 0.0.0.0:8001, 0.0.0.0:8444 SSL" -p 8000:8000 -p 8443:8443 -p 8001:8001 -p 8444:8444 kong:latest
Copy the code

3 the agent

3.1 Basic Information

8000: This port is what Kong uses to listen for HTTP requests from clients and forward them to your upstream service. This is the main port used in this tutorial.

8443: This is the port on which Kong listens for HTTP requests. This port has similar behavior to port 8000, but it only listens for HTTPS requests and does not generate forwarding behavior. This port can be disabled through a configuration file.

8001: port used by the administrator to configure KONG.

8444: Port for the administrator to listen for HTTPS requests.

3.2 Configuring a Simple Proxy

3.2.1 Creating a Service

Curl - I - X POST \ \ - url http://172.16.60.8:8001/services/ - data 'name = example - service \ - data 'url=https://www.baidu.com'Copy the code

3.2.2 Adding a Route

Curl - I - X POST \ \ - url http://172.16.60.8:8001/services/example-service/routes - data 'hosts [] = baidu.com' \ - data 'paths[]=/proxy/baidu'Copy the code

3.2.3 Access tests

4 Konga installation

4.1 Preparing a Database

docker run --network=kong-net --rm pantsel/konga -c prepare -a postgres -u postgresql://konga:konga@kong-database/konga
Copy the code

4.2 the deployment

4.2.1 Container Deployment

docker run -d -p 1337:1337 --name kong-konga \ 
--network=kong-net \ 
-e "TOKEN_SECRET=${generate a random}" \ 
-e "DB_ADAPTER=postgres" \ 
-e "DB_HOST=kong-database" \ 
-e "DB_PORT=5432" \ 
-e "DB_USER=konga" \ 
-e "DB_PASSWORD=konga" \ 
-e "DB_DATABASE=konga" \ 
-e "NODE_ENV=development" \ 
pantsel/konga
Copy the code

4.2.2 Local Deployment

$$CD konga $NPM git clone https://github.com/pantsel/konga.git I # configuration file. The env_example NPM run productionCopy the code

4.3 Konga Connects to Kong

5 Authentication

5.1 What is Authentication?

API gateway authentication is an important way to control the data you are allowed to transfer using your API. Basically, it uses a predefined set of credentials to check whether a particular consumer has access to the API.

Kong Gateway has a library of plug-ins that provide a simple way to implement the best known and most widely used methods of API Gateway authentication. Here are some commonly used ones:

  • Basic authentication
  • Key authentication
  • OAuth 2.0 authentication
  • LDAP Advanced Authentication
  • OpenID connection

5.2 Why USE API Gateway Authentication?

With authentication enabled, Kong Gateway does not broker requests unless the client first successfully authenticates.

This means that upstream (APIS) do not need to authenticate client requests and do not waste critical resources used to validate credentials.

The Kong Gateway can view all authentication attempts (successful, failed, and so on) so that these events can be categorized and controlled to demonstrate that appropriate controls exist and achieve compliance. Authentication also gives you the opportunity to determine how failed requests will be handled. This may mean only blocking the request and returning an error code, or in some cases, you may still want to provide limited access.

5.3 Key Authentication (Key-Auth)

5.3.1 Enabling Key Authentication

Call the Admin API 8001 on the port and configure the plug-in to enable key authentication. For this example, apply the plug-in to the b0DB420A-D3C3-45EE-8B25-11f3FD8CA283 route that you created.

The curl -x POST http://172.16.60.8:8001/routes/b0db420a-d3c3-45ee-8b25-11f3fd8ca283/plugins -- data name = "key - auth" { "created_at": 1609208272, "id": "81382fb7-1b7f-478b-848e-965863f36165", "tags": null, "enabled": true, "protocols": ["grpc", "grpcs", "http", "https"], "name": "key-auth", "consumer": null, "service": null, "route": { "id": "b0db420a-d3c3-45ee-8b25-11f3fd8ca283" }, "config": { "key_names": ["apikey"], "run_on_preflight": true, "anonymous": null, "hide_credentials": false, "key_in_body": false } }Copy the code

5.3.2 Attempted Access

The curl -i http://172.16.60.8:8000/api/oss/ HTTP / 1.1 401 Unauthorized Date: Tue, 29 Dec 2020 02:20:20 GMT the content-type: application/json; charset=utf-8 Connection: keep-alive WWW-Authenticate: Key realm="kong" Content-Length: 45 X-Kong-Response-Latency: 30 Server: kong/2.2.1 {"message":"No API key found in request"}Copy the code

Before the Kong agent can request this route, it needs an API key. For this example, because the key authentication plug-in is installed, you need to first create a consumer with an associated key.

5.3.3 Creating a User

Curl - I - X POST \ \ - url http://172.16.60.8:8001/consumers/ - data "username = Apiuser" HTTP / 1.1 201 Created Date: Tue, 29 Dec 2020 02:26:39 GMT Content-Type: application/json; charset=utf-8 Connection: keep-alive Access-Control-Allow-Origin: * Content-Length: 119 X-Kong-Admin-Latency: 12 Server: kong/2.2.1 {" custom_ID ": null, "creATED_at ": 1609208799, "id": "c469d8ad-723c-4c95-bbb1-f3a06ba74555", "tags": null, "username": "Apiuser" }Copy the code

5.3.4 Creating a Key for a User

The curl - I - X POST \ \ - url http://172.16.60.8:8001/consumers/Apiuser/key-auth/ - data 'key = XXZX @ 789 HTTP / 1.1 201 Created  Date: Tue, 29 Dec 2020 02:28:08 GMT Content-Type: application/json; charset=utf-8 Connection: keep-alive Access-Control-Allow-Origin: * Content-Length: 166 X-Kong-Admin-Latency: 11 Server: kong/2.2.1 {" creATED_at ": 1609208888, "id": "315e4864-74A3-4fb9-910A-4b48909371F8 ", "tags": NULL," TTL ": null, "key": "xxzx@789", "consumer": { "id": "c469d8ad-723c-4c95-bbb1-f3a06ba74555" } }Copy the code

5.3.5 Using key Access Tests

Data is successfully obtained

The curl -i http://172.16.60.8:8000/api/oss/ - H 'apikey: XXZX @ 789 HTTP / 1.1 201 Created the content-type: application/json. Charset =UTF-8 Content-Length: 299 Connection: keep-alive Server: TornadoServer/5.1.1 Date: Tue, 29 Dec 2020 02:30:00 GMT Access-Control-Allow-Methods: POST Access-Control-Allow-Origin: * x-kong-proxy-latency: 1 Via: Kong /2.2.1 {"requestId": "C00313f2-497d-11eb-a0c9-e6fb0f2261ab "," TIMESTAMP ": "2020-12-29t10:30:00.609927", "status": 201, "data": "Welcome to use Go2cloud API OSS server. If you want to know about\n more detail of API content. pls can connect our staff worker.\n Thanks! \n ", "path": "/" }Copy the code

5.4 Basic Verification (Basic-AUTH)

5.4.1 CLI configuration

1. Configure the plug-in on the service with the following request:

$ curl -X POST http://kong:8001/services/{service}/plugins \
    --data "name=basic-auth"\ -data "config.hide_credentials=true"
Copy the code

2. Enable plugins on routing:

$ curl -X POST http://kong:8001/routes/{route_id}/plugins \
    --data "name=basic-auth"\ -data "config.hide_credentials=true"
Copy the code

5.4.2 Konga Management Platform Configuration

5.4.2.1 Adding basic-Auth plug-in for routes

5.4.2.2 Creating a User and Setting credentials

5.4.3 Pass the Postman test

6 safety

6.1 the ACL authentication

6.1.1 Enabling plug-ins

Enable the plug-in on the service

$ curl -X POST http://kong:8001/services/{service}/plugins \
    --data "name=acl"\ -data "config.whitelist=group1, group2"\ -data "config.hide_groups_header=true"
Copy the code

Enable plug-ins on routes

$ curl -X POST http://kong:8001/routes/{route_id}/plugins \
    --data "name=acl"\ -data "config.whitelist=group1, group2"\ -data "config.hide_groups_header=true"
Copy the code
curl -X POST http://localhost:8001/routes/b0db420a-d3c3-45ee-8b25-11f3fd8ca283/plugins \
--data "name=acl" \
--data "config.whitelist=devops" \
--data "config.hide_groups_header=true"     

{
	"created_at": 1609210608,
	"id": "c0256ae6-271c-44d8-bee3-f11d36e05abb",
	"tags": null,
	"enabled": true,
	"protocols": ["grpc", "grpcs", "http", "https"],
	"name": "acl",
	"consumer": null,
	"service": null,
	"route": {
		"id": "b0db420a-d3c3-45ee-8b25-11f3fd8ca283"
	},
	"config": {
		"allow": ["devops"],
		"hide_groups_header": true,
		"deny": null
	}
}
Copy the code

6.1.2 Access Tests

Because ACL authentication is enabled, users cannot access the service

6.1.3 Adding Users to an Authorized DevOPS Group

Curl -x POST http://127.0.0.1:8001/consumers/basic/acls -- data group = "conversation" {" created_at ": 1609210724," id ": "6e066cff-b8ea-4d6e-b412-e3d39509c342", "group": "devops", "tags": null, "consumer": { "id": "7e9ac7ce-5a8e-4bce-8baa-cf09a7aa5c47" } }Copy the code

6.2 IP restrictions

6.2.1 Enabling the IP Address Restriction plug-in

1. Enable the plug-in on the service

$ curl -X POST http://kong:8001/services/{service}/plugins \
    --data "name=ip-restriction"\ -data "Config. Whitelist = 54.13.21.1, 143.1.0.0/24"
Copy the code

2. Enable the plug-in on the route

$ curl -X POST http://kong:8001/routes/{route_id}/plugins \
    --data "name=ip-restriction"\ -data "Config. Whitelist = 54.13.21.1, 143.1.0.0/24"
Copy the code

Config. whitelist: Indicates a comma separated IPs or CIDR range. Config. blacklist: whitelist, comma separated IPs or CIDR range.

Curl -x POST http://127.0.0.1:8001/routes/b0db420a-d3c3-45ee-8b25-11f3fd8ca283/plugins \ - data "name = IP - restriction \" --data "config.whitelist=172.16.60.9" {" creATED_at ": 1609211384, "id": "e6AD04AF-6484-482C-AEa7-2C70243EF835 ", "tags": null, "enabled": true, "protocols": ["grpc", "grpcs", "http", "https"], "name": "ip-restriction", "consumer": null, "service": null, "route": { "id": "b0db420a-d3c3-45ee-8b25-11f3fd8ca283" }, "config": { "allow": ["172.16.60.9"], "deny": null}}Copy the code

6.2.2 Test Access

The current IP address of the host is 172.24.107.55

6.2.3 Adding IP addresses to the Whitelist

6.2.4 Test access again

6.3 Crawler control

6.3.1 Enabling the crawler control plug-in

1. Enable the plug-in on the service

$ curl -X POST http://kong:8001/services/{service}/plugins \
    --data "name=bot-detection" 
Copy the code

2. Enable the plug-in on the route

$ curl -X POST http://kong:8001/routes/{route_id}/plugins \
    --data "name=bot-detection" 
Copy the code

Config. whitelist: a comma-separated array of regular expressions. The regular expression is matched against the User-Agent header. Config. blacklist: a comma-separated array of regular expressions. The regular expression is matched against the User-Agent header.

7 Flow Control

7.1 Request Size Limit

Prevents incoming requests whose body is larger than a certain size of megabytes

7.1.1 Enabling The Size Limit

1. Enable the plug-in on the service

$ curl -X POST http://kong:8001/services/{service}/plugins \
    --data "name=request-size-limiting"\ -data "config.allowed_payload_size=128"
Copy the code

2. Enable the plug-in on the route

$ curl -X POST http://kong:8001/routes/{route_id}/plugins \
    --data "name=request-size-limiting"\ -data "config.allowed_payload_size=128"
Copy the code

Enable the plug-in in the consumer

$ curl -X POST http://kong:8001/plugins \
    --data "name=request-size-limiting"\ -data "consumer_id={consumer_id}"\ -data "config.allowed_payload_size=128"
Copy the code
The curl -x POST http://172.16.60.8:8001/routes/b0db420a-d3c3-45ee-8b25-11f3fd8ca283/plugins \ - data "name=request-size-limiting" \ --data "config.allowed_payload_size=-20" { "created_at": 1609212809, "id": "08112606-e023-4d1b-ba76-853832585feb", "tags": null, "enabled": true, "protocols": ["grpc", "grpcs", "http", "https"], "name": "request-size-limiting", "consumer": null, "service": null, "route": { "id": "b0db420a-d3c3-45ee-8b25-11f3fd8ca283" }, "config": { "size_unit": "megabytes", "allowed_payload_size": -20 } }Copy the code

7.1.2 Access Tests

7.2 Request Rate Limit

Rate limits how many HTTP requests a developer can make in a given time, minute, hour, day, month, or year

7.2.1 Enabling Rate Limiting

1. Enable the plug-in on the service

$ curl -X POST http://kong:8001/services/{service}/plugins \
    --data "name=rate-limiting"\ -data "config.second=5"\ -data "config.hour=10000"
Copy the code

2. Enable the plug-in on the route

$ curl -X POST http://kong:8001/routes/{route_id}/plugins \
    --data "name=rate-limiting"\ -data "config.second=5"\ -data "config.hour=10000"
Copy the code

Enable the plug-in in the consumer

$ curl -X POST http://kong:8001/plugins \
    --data "name=rate-limiting"\ -data "consumer_id={consumer_id}"\ -data "config.second=5"\ -data "config.hour=10000"
Copy the code
Curl -x POST http://172.16.60.8:8001/routes/b0db420a-d3c3-45ee-8b25-11f3fd8ca283/plugins \ - data "name = rate - limiting \"  --data "config.second=2" \ --data "config.hour=10000" { "created_at": 1609213117, "id": "0329fd21-3844-4a84-b325-68282577c78a", "tags": null, "enabled": true, "protocols": ["grpc", "grpcs", "http", "https"], "name": "rate-limiting", "consumer": null, "service": null, "route": { "id": "b0db420a-d3c3-45ee-8b25-11f3fd8ca283" }, "config": { "minute": null, "redis_host": null, "redis_timeout": 2000, "limit_by": "consumer", "hour": 10000, "policy": "cluster", "month": null, "redis_password": null, "second": 2, "day": null, "hide_client_headers": false, "path": null, "redis_database": 0, "year": null, "redis_port": 6379, "header_name": null, "fault_tolerant": true } }Copy the code

7.2.2 Access Tests

7.3 Request Termination

The plug-in terminates incoming requests with the specified status code and message. This allows (temporarily) stopping traffic on a service or route (or deprecated API entity), or even blocking users

7.3.1 Enabling the request termination plug-in

1. Enable the plug-in on the service

$ curl -X POST http://kong:8001/services/{service}/plugins \
    --data "name=request-termination"\ -data "config.status_code=403"\ -data "config.message=So long and thanks for all the fish!"
Copy the code

2. Enable the plug-in on the route

$ curl -X POST http://kong:8001/routes/{route_id}/plugins \
    --data "name=request-termination"\ -data "config.status_code=403"\ -data "config.message=So long and thanks for all the fish!"
Copy the code
The curl -x POST http://172.16.60.8:8001/routes/b0db420a-d3c3-45ee-8b25-11f3fd8ca283/plugins \ - data "name=request-termination" \ --data "config.status_code=403" \ --data "config.message=The service is under maintenance" { "created_at": 1609213373, "id": "77c99041-0a99-4388-b4fa-9378791c3839", "tags": null, "enabled": true, "protocols": ["grpc", "grpcs", "http", "https"], "name": "request-termination", "consumer": null, "service": null, "route": { "id": "b0db420a-d3c3-45ee-8b25-11f3fd8ca283" }, "config": { "status_code": 403, "content_type": null, "body": null, "message": "The service is under maintenance" } }Copy the code

7.3.2 Access Tests

7.3.3 remark

  • Config.status_code: response code to be sent.
  • Config. message: The message to send if the default response generator is used.
  • Config. body: The body of the raw response to be sentconfig.messageMutually exclusive
  • The config. Content_type: forconfig.bodyConfigure the content type of the RAW response. Default:application/json; charset=utf-8