首页 文章 精选 留言 我的

将 NGINX 部署为 API 网关，第 2 部分：保护后端服务

2022-10-19 345

原文作者：Liam Crilly of F5

原文链接：将 NGINX 部署为 API 网关，第 2 部分：保护后端服务

转载来源：NGINX 官方网站

本文是将 NGINX 开源版和 NGINX Plus 部署为 API 网关系列博文的第二篇。

注：除非另有说明，否则本文中的所有信息都适用于 NGINX 开源版和 NGINX Plus。为了便于阅读，下文将 NGINX 开源版和 NGINX Plus 统称为“NGINX”。

限流

与基于浏览器的客户端不同，单个 API 客户端就能够给您的 API 造成巨大的负载，甚至会消耗大量的系统资源，以致其他 API 客户端因此被“排挤”。不仅恶意客户端会构成这种威胁，行为异常或存在缺陷的 API 客户端也可能会反复压垮后端。为了防止出现这种情况，我们用限流来确保每个客户端合理使用 API 并保护后端服务的资源。

NGINX 可以根据请求的任何属性应用限流。通常使用客户端 IP 地址，但如果为 API 启用身份验证，则经过身份验证的客户端 ID 将是更为可靠和准确的属性。

限流本身在顶层 API 网关配置文件中定义，并且可以全局、按每个API 甚至每个 URI 来应用。

include api_backends.conf;
include api_keys.conf;

limit_req_zone $binary_remote_addr zone=client_ip_10rs:1m rate=10r/s; limit_req_zone $http_apikey        zone=apikey_200rs:1m   rate=200r/s;

server {
    access_log /var/log/nginx/api_access.log main; # Each API may also log to a 
                                                  # separate file

    listen 443 ssl;
    server_name api.example.com;

    # TLS config
    ssl_certificate      /etc/ssl/certs/api.example.com.crt;
    ssl_certificate_key  /etc/ssl/private/api.example.com.key;
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  5m;
    ssl_ciphers          HIGH:!aNULL:!MD5;
    ssl_protocols        TLSv1.2 TLSv1.3;

    # API definitions, one per file
    include api_conf.d/*.conf;

    # Error responses
    error_page 404 = @400;         # Invalid paths are treated as bad requests
    proxy_intercept_errors on;     # Do not send backend errors to the client
    include api_json_errors.conf;  # API client friendly JSON error responses
    default_type application/json; # If no content-type then assume JSON
}

在此示例中，第 4 行的limit_req_zone指令为每个客户端 IP 地址 ($binary_remote_addr) 定义每秒 10 个请求的限流，第 5 行的 limit_req_zone 指令为每个经过身份验证的客户端 ID ($http_apikey) 定义每秒 200 个请求的限流。该示例说明了我们可以定义多个限流，而不受它们所应用位置的约束。一个 API 可以同时应用多个限流，或者对不同的资源应用不同的限流。

在下面的配置段中，我们使用limit_req指令来应用本系列博文第 1 部分中描述的“Warehouse API”策略部分中的第一个限流。默认情况下，当超过限流阈值时，NGINX 会发送503``(Service``Unavailable)响应。然而，让 API 客户端明确地知道自己已超过限流阈值，有助于它们调整自己的行为。为此，我们使用limit_req_status指令来发送429``(Too``Many``Requests)响应。

 # Warehouse API
#
location /api/warehouse/ {
    # Policy configuration here (authentication, rate limiting, logging...)
    #
    access_log /var/log/nginx/warehouse_api.log main;
    limit_req zone=client_ip_10rs;
    limit_req_status 429;

    # URI routing
    #
    location /api/warehouse/inventory {
        limit_except GET {
            deny all;
        }
        error_page 403 = @405; # Convert deny response from '403 (Forbidden)'
                               # to '405 (Method Not Allowed)'
        proxy_pass http://warehouse_inventory;
    }

    location /api/warehouse/pricing {
        limit_except GET PATCH {
            deny all;
        }
        error_page 403 = @405;
        proxy_pass http://warehouse_pricing;
    }

    return 404; # Catch-all
}

您可以使用limit_req指令的附加参数来微调 NGINX 执行限流的方式。例如，当超过限流阈值时，可以让请求排队而不是直接拒绝它们，从而使请求速率有时间降至定义的限制之下。有关微调限流阈值的更多信息，请参阅我们的博文《使用NGINX 和 NGINX Plus 实现限流》。

限定请求方法

对于 RESTful API，HTTP 方法是每个 API 调用的重要组成部分，对 API 定义非常重要。以Warehouse API 的定价服务 service 为例：

  • GET``/api/warehouse/pricing/item001        returns the price of item001
  • PATCH``/api/warehouse/pricing/item001   changes the price of item001

我们可以更新Warehouse API 中的 URI 路由定义，以便在对定价 service 的请求中只接受这两个 HTTP 方法（并且在对库存 service 的请求中只接受GET方法）。

    # URI routing
    #
    location /api/warehouse/inventory {
        limit_except GET {
            deny all; 
        }
        error_page 403 = @405; # Convert deny response from '403 (Forbidden)'
                               # to '405 (Method Not Allowed)'
        proxy_pass http://warehouse_inventory;
    }

    location /api/warehouse/pricing {
        limit_except GET PATCH {
            deny all;
        }
        error_page 403 = @405; # Convert deny response from '403 (Forbidden)'
                               # to '405 (Method Not Allowed)'
        proxy_pass http://warehouse_pricing;
    }

使用此配置后，未使用第 22 行所列方法向定价 service 发出的请求（以及未使用第 13 行所列方法对库存 service 进行请求）将被拒绝，并且不会传递到后端 service 。NGINX 发送405``(Method``Not``Allowed)响应，以通知 API 客户端确切的错误类型，如以下控制台跟踪所示。在需要遵循“最小披露”的安全策略时，可使用error_page指令将此响应转换为信息量较少的错误，例如400``(Bad``Request)。

$ curl https://api.example.com/api/warehouse/pricing/item001
{"sku":"item001","price":179.99}
$ curl -X DELETE https://api.example.com/api/warehouse/pricing/item001
{"status":405,"message":"Method not allowed"}

应用细粒度的访问控制

本系列博文的第 1 部分介绍了如何通过启用身份验证选项（例如API 密钥和JSON Web Tokens (JWT)）保护 API 免受未经授权的访问。我们可以使用经过身份验证的 ID 或经过身份验证的 ID 的属性来执行细粒度的访问控制。

我们在此处提供了两个相关示例：

当然，其他认证方式也适用于这些示例中的用例，例如HTTP Basic 认证和OAuth 2.0 令牌自省。

控制对特定资源的访问

假设我们只允许“基础设施客户端”访问Warehouse API 库存 service 的audit资源。启用 API Key 认证方式后，我们使用map块创建基础设施客户端名称的允许名单，以便在使用相应的 API Key时变量$is_infrastructure的计算结果为1。

map $api_client_name $is_infrastructure {
    default       0;

    "client_one"  1;
    "client_six"  1;
}

在Warehouse API 的定义中，我们为库存audit资源添加了一个location块（第 15-20 行）。if块可确保只有基础设施客户端可以访问该资源。

# Warehouse API
#
location /api/warehouse/ {
    # Policy configuration here (authentication, rate limiting, logging...)
    #
    access_log /var/log/nginx/warehouse_api.log main;
    auth_request /_validate_apikey;
 
    # URI routing
    #
    location /api/warehouse/inventory {
        proxy_pass http://warehouse_inventory;
    }
 
    location = /api/warehouse/inventory/audit {
        if ($is_infrastructure = 0) {
            return 403; # Forbidden (not infrastructure)
        }
        proxy_pass http://warehouse_inventory;
    }
 
    location /api/warehouse/pricing {
        proxy_pass http://warehouse_pricing;
    }
 
    return 404; # Catch-all
}

请注意，第 15 行的location指令使用=（等号）修饰符与audit资源进行精确匹配。精确匹配优先于用于其他资源的默认路径前缀定义。以下跟踪显示了在使用此配置的情况下，不在允许名单上的客户端如何无法访问库存audit资源。所示 API Key属于client_two（如第 1 部分中所定义）。

$ curl -H "apikey: QzVV6y1EmQFbbxOfRCwyJs35" 
https://api.example.com/api/warehouse/inventory/audit
{"status":403,"message":"Forbidden"}

控制对特定方法的访问

如上所述，定价 service 接受GET和PATCH方法，分别支持客户端获取和修改特定物品的价格。（我们还可以选择允许POST和DELETE方法，以提供定价数据的全生命周期管理。）在本部分，我们对该用例进行扩展，控制特定用户可以发出哪些方法。为Warehouse API 启用 JWT 身份验证后，每个客户端的权限都被编码为自定义声明。发给授权更改定价数据的管理员的 JWT 包含声明"admin":true。现在，我们扩展了访问控制逻辑，以便只有管理员才能进行更改。

# Access to write operations is evaluated by JWT claim 'admin'
map $request_method $admin_permitted_method {
    "GET" 	true;
    "HEAD"	true;
    "OPTIONS" true;
    default   $jwt_claim_admin;
}

此map块（被添加到api_gateway.conf的底部）将请求方法 ($request_method) 作为输入并生成一个新变量$admin_permitted_method。只读方法始终允许（第 62-64 行），但对写入操作的访问取决于 JWT 中admin声明的值（第 65 行）。我们现在扩展了Warehouse API 配置，以确保只有管理员才能更改定价。

# Warehouse API
#
location /api/warehouse/ {
    # Policy configuration here (authentication, rate limiting, logging...)
    #
    access_log /var/log/nginx/warehouse_api.log main;
    auth_jwt "Warehouse API";
    auth_jwt_key_file /etc/nginx/idp_jwks.json;
 
    # URI routing
    #
    location /api/warehouse/inventory {
        limit_except GET {
            deny all;
        }
        error_page 403 = @405; # Convert deny response from '403 (Forbidden)'
                               # to '405 (Method Not Allowed)'
        proxy_pass http://warehouse_inventory;
    }
    
    location /api/warehouse/pricing {
        limit_except GET PATCH {
            deny all;
        }
        if ($admin_permitted_method != "true") {
            return 403;
        }
        error_page 403 = @405; # Convert deny response from '403 (Forbidden)'
                               # to '405 (Method Not Allowed)'
        proxy_pass http://warehouse_pricing;
    }
 
    return 404; # Catch-all
}

Warehouse API 要求所有客户端都提供有效的 JWT（第 7 行）。我们还通过评估$admin_permitted_method变量（第 25 行）来检查是否允许写入操作。再次提醒，JWT 身份验证是 NGINX Plus 的独有功能。

控制请求大小

HTTP API 通常使用请求正文来包含后端 API service要处理的指令和数据。XML/SOAP API 以及 JSON/REST API 也是如此。因此，请求正文可能会构成后端 API service 的攻击向量，当后端 API service 处理超大的请求正文时，可能容易受到缓冲区溢出攻击。

默认情况下，NGINX 拒绝正文大于 1MB 的请求。对于专门处理大型负载（例如图像处理）的 API，此值可以增加，但对于大多数 API，我们会设置一个较低的值。

# Warehouse API
#
location /api/warehouse/ {
    # Policy configuration here (authentication, rate limiting, logging...)
    #
    access_log /var/log/nginx/warehouse_api.log main;
    client_max_body_size 16k;

第 7 行的client_max_body_size指令限制了请求正文的大小。有了此配置，我们就可以比较 API 网关在接收到两个不同的PATCH定价 service 请求时的行为。第一个curl命令发送一小段 JSON 数据，而第二个命令则尝试发送一个大文件 (/etc/services) 的内容。

$ curl -iX PATCH -d '{"price":199.99}' https://api.example.com/api/warehouse/pricing/item001
HTTP/1.1 204 No Content
Server: nginx/1.19.5
Connection: keep-alive

$ curl -iX PATCH -d@/etc/services https://api.example.com/api/warehouse/pricing/item001
HTTP/1.1 413 Request Entity Too Large
Server: nginx/1.19.5
Content-Type: application/json
Content-Length: 45
Connection: close

{"status":413,"message":"Payload too large"}

验证请求正文

[编者按—— 以下用例是 NGINX JavaScript 模块几个用例之一。查看完整列表，请参阅《NGINX JavaScript 模块的用例》]。

除了容易受到大型请求正文的缓冲区溢出攻击之外，后端 API service 还容易受到包含无效或意外数据的正文的影响。对于需要请求正文具有正确格式的 JSON 的应用，我们可以在将 JSON 数据代理到后端 API service 之前，使用NGINX JavaScript 模块验证其解析是否正确。

安装 JavaScript 模块后，我们使用js_import指令来引用包含 JSON 数据验证函数的 JavaScript 代码的文件。

js_import json_validation.js;
js_set $json_validated json_validation.parseRequestBody;

js_set指令定义了一个新变量$json_validated，通过调用parseRequestBody函数对其进行计算。

export default { parseRequestBody };

function parseRequestBody(r) {
    try {
        if (r.variables.request_body) {
            JSON.parse(r.variables.request_body);
        }
        return r.variables.upstream;
    } catch (e) {
        r.error('JSON.parse exception');
        return '127.0.0.1:10415'; // Address for error response
    }
}

parseRequestBody函数尝试使用JSON.parse方法（第 6 行）解析请求正文。如果解析成功，则返回此请求所需上游 group 的名称（第 8 行）。如果无法解析请求正文（导致异常），则返回本地服务器地址（第 11 行）。return指令将填充$json_validated变量，以便我们可以使用它来确定将请求发送到何处。

# URI routing
    #
    location /api/warehouse/inventory {
        proxy_pass http://warehouse_inventory;
    }

    location /api/warehouse/pricing {
        set $upstream warehouse_pricing;
        mirror /_get_request_body;        # Force early read
        client_body_in_single_buffer on;  # Minimize memory copy operations 
                                          # on request body
        client_body_buffer_size      16k; # Largest body to keep in memory 
                                          # (before writing to file)
        client_max_body_size         16k;
        proxy_pass http://$json_validated$request_uri;
    }

在Warehouse API 的 URI 路由部分，我们在第 22 行修改了proxy_pass指令。它将请求传递给后端 API service ，如前面部分中讨论的Warehouse API 配置一样，但是现在使用$json_validated变量作为目标地址。如果客户端正文被成功解析为 JSON，那么我们将代理到第 15 行定义的上游 group。但是，如果出现异常，我们将使用返回值127.0.0.1:10415向客户端发送错误响应。

server {
    listen 127.0.0.1:10415;
    return 415; # Unsupported media type
    include api_json_errors.conf;
}

当请求被代理到这个虚拟服务器时，NGINX 将向客户端发送415``(Unsupported``Media``Type)) 响应。

有了这个完整的配置，NGINX 将只在请求具有正确格式的 JSON 正文时才将其代理到后端 API service 。

$ curl -iX POST -d '{"sku":"item002","price":85.00}' https://api.example.com/api/warehouse/pricing
HTTP/1.1 201 Created
Server: nginx/1.19.5
Location: /api/warehouse/pricing/item002

$ curl -X POST -d 'item002=85.00' https://api.example.com/api/warehouse/pricing
{"status":415,"message":"Unsupported media type"}

关于$request_body变量的说明

JavaScript 函数parseRequestBody使用$request_body变量来执行 JSON 解析。但是，NGINX 默认不赋值此变量，只是将请求正文流式传输到后端而创建中间副本。我们通过在 URI 路由部分（第 16 行）使用mirror指令，创建客户端请求的副本，并赋值$request_body变量。

location /api/warehouse/pricing {
        set $upstream warehouse_pricing;
        mirror /_get_request_body;        # Force early read
        client_body_in_single_buffer on;  # Minimize memory copy operations 
                                          # on request body
        client_body_buffer_size      16k; # Largest body to keep in memory 
                                          # (before writing to file)
        client_max_body_size         16k;
        proxy_pass http://$json_validated$request_uri;
    }

第 17 行和第 19 行的指令控制 NGINX 如何在内部处理请求正文。我们将client_body_buffer_size设置为与client_max_body_size相同的大小，这样请求正文就不会写入磁盘。这样做有助于最大限度地减少磁盘 I/O 操作，从而提高整体性能，但代价是内存利用率会有所增加。对于大多数请求正文较小的 API 网关用例，这是一个不错的折衷方案。

如前所述，mirror指令会创建客户端请求的副本。除了赋值$request_body之外，我们不需要此副本，因此我们将其发送到我们在顶层 API 网关配置的server块中定义的“死胡同（dead end）”位置 (/_get_request_body)。

# Dummy location used to populate $request_body for JSON validation
    location = /_get_request_body {                                                                                                   
        return 204;
    }

此位置只发送204``(No``Content)响应。此响应与镜像请求相关，因此被忽略，对原始客户端请求的处理所增加的开销也可以忽略不计。

总结

本文是将 NGINX 开源版和 NGINX Plus 部署为 API 网关系列博文的第二篇，主要关注如何保护生产环境中的后端 API service 免受恶意和行为异常的客户端的影响。NGINX 所使用的 API 流量管理技术同样被用于支持和保护当今互联网上最繁忙的站点。

查看本系列博文的其他文章：

  • 第 1 部分解释了如何在一些基本的 API 网关用例中配置 NGINX。
  • 第 3 部分解释了如何将 NGINX 部署为 gRPC 服务的 API 网关。

更多资源

想要更及时全面地获取 NGINX 相关的技术干货、互动问答、系列课程、活动资源？

请前往 NGINX 开源社区：

上一篇 下一篇
优秀的个人博客,低调大师

微信关注我们

原文链接：https://my.oschina.net/u/5246775/blog/5585208

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

一文读懂：开源大数据调度系统Taier1.2版本新增的「工作流」到底是什么？

一、什么是工作流？ 在阐述什么是工作流之前，先说一下工作流和普通任务的区别，在于依赖视图。 普通任务本身他只会有自己的dag图，依赖视图是无边界的，不可控的，而工作流则是把整个工作流都展示出来，是有边界的，可控的，这是工作流的优势。下面为大家介绍工作流的相关功能： 01 工作流—功能介绍 ● 虚拟节点 虚拟节点，它是不产生任何数据的空跑节点（即调度到该节点时，系统直接返回成功，不会真正执行、不会占用资源或阻塞下游节点运行），比如说任务并行执行，那么就会用到虚拟节点。 ● 周期生成 指调度系统按照调度配置自动定时运行的任务。 ● 补数据运行 当业务变更，可以使用补数据功能。如修改了某个任务的代码，可将本月的数据按照新的代码重新跑一遍，立即生成所需数据。 ● 调度属性 工作流中的子任务依赖于父任务的周期调度属性，父任务修改后，子任务同步修改，以工作流的周期调度属性作为各个子节点的周期调度时间。 ● 工作流所在目录 修改工作流目录同步修改工作流下的子任务目录。 02 工作流—依赖成环 具体实现： 任务完成依赖的关系，key为当前节点，value为该节点的所有父节点Map < long ...
2022-10-18
348
上一篇

揭秘百度智能测试在测试评估领域实践

作者 | intelligents 前几篇，分布介绍了测试活动测试输入、测试执行、测试分析、测试定位和测试评估五个步骤中测试输入、执行、分析的智能化研究和实践，本章节重点介绍测试评估环节的智能化实践。 测试评估是通过收集质量保障活动过程产生的各类系统表现数据，利用策略进行分析，以进一观测经过全部质量活动后的质量风险，此次分析区别于测试报告，如性能测试报告、功能测试报告，测试报告是针对某项质量活动揭露有无问题的报告，测试评估是从风险程度去判断是否要增加质量活动。测试评估往往是质量保障人员最容易忽视的环节，但随着测试自动化程度水平的提升，测试人员往往只通过自动化报告去判断质量风险，而缺少必要的分析，极容易造成漏测。 测试评估智能化通过将数据、算法、工程等相关技术有机结合，从质量活动系统表现数据、变更风险程度等方面，利用策略或算法预估项目准出的风险，以最终决定项目是否可以上线。测试评估的研究主要从风险引入、质量活动数据挖掘、风险度评估等多个领域进行研究，在该领域的实践相对较少，百度QA一直在探索研究和实践。本章节将从对应实践角度，介绍相关领域的目标、思路，涉及到的技术点、效果，希望能给到大家...
2022-10-19
347
下一篇

相关文章

发表评论

资源下载

更多资源
优质分享App

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

时间: 2025-12-03 大小: 4.36MB 下载: 23次
Oracle

Oracle

Oracle Database，又名Oracle RDBMS，或简称Oracle。是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。可以说Oracle数据库系统是目前世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的、适应高吞吐量的数据库方案。

时间: 2025-12-03 大小: 2.6GB 下载: 112次
Apache Tomcat

Apache Tomcat

Tomcat是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目，由Apache、Sun 和其他一些公司及个人共同开发而成。因为Tomcat 技术先进、性能稳定，而且免费，因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可，成为目前比较流行的Web 应用服务器。

时间: 2025-12-03 大小: 10MB 下载: 35次
JDK

JDK

JDK是 Java 语言的软件开发工具包，主要用于移动设备、嵌入式设备上的java应用程序。JDK是整个java开发的核心，它包含了JAVA的运行环境（JVM+Java系统类库）和JAVA工具。

时间: 2025-12-03 大小: 180MB 下载: 76次
手机查看

扫码在手机上查看文章

扫描二维码，手机阅读更方便

热门标签
SpringCloud K8s DeepSeek 服务网格 SpringBoot Nacos Redis ChatGPT Jdk25 HarmonyOS NEXT Docker

欢迎您！

登录后，您将获得更多功能！

热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273