NGINX.COM

NGINX Ingress Controller 1.10.0 起已正式支持 OpenID Connect (OIDC) 身份验证技术预览版。OIDC 是建立在 OAuth 2.0 框架之上的身份层,为现代应用提供了身份验证和单点登录 (SSO) 解决方案。我们的 OIDC 策略是一种成熟的 SSO 解决方案,能够支持用户安全地与多个应用和 Kubernetes 服务进行身份验证。重要的是,它支持应用使用外部身份提供商 (IdP) 来验证用户身份,卸除了应用处理用户名或密码的负担。

这个新功能是对其他 NGINX Ingress Controller 授权和身份验证功能 (例如 JSON Web Token (JWT) 身份验证)的补充,提供了一个功能强大的单点登录选项,可配合 NGINX Ingress 资源轻松进行配置。这意味着您可以使用久经实战考验的解决方案对用户进行身份验证和授权,且开发人员无需在应用中实施这些功能,便可保障应用安全。通过在 Ingress Controller 上实施安全措施和流量控制,您可以在连接的早期阶段拦截未经授权和身份验证的用户,从而减少 Kubernetes 环境中不必要的资源压力。

定义 OIDC 策略

通过定义和应用 OIDC 策略,NGINX Plus Ingress Controller 可以作为 OIDC 中继方运行,能够启动并容许经过身份验证的 Kubernetes 服务会话(服务的入向流量)。我们通过预配置的 IdP 支持 OIDC 授权代码流

注: OIDC 策略是 NGINX Plus 的专有特性。

以下是一个 OIDC 策略对象配置示例。

apiVersion: k8s.nginx.org/v1alpha1
kind: Policy
metadata:
  name: ingress-oidc-policy
spec:
  oidc:
    clientID: nginx-ingress
    clientSecret: oidc-secret
    authEndpoint: https://idp.example.com/openid-connect/auth
    tokenEndpoint: https://idp.example.com/openid-connect/token 
    jwksURI: https://idp.example.com/openid-connect/certs

下面介绍了如何在建立 OIDC 会话时使用策略中的对象:

  1. 客户端请求访问受保护的资源,NGINX Plus Ingress Controller 将其重定向到指定为 authEndpoint 的 IdP 进行身份验证。
  2. 如果身份验证成功,IdP 会发出一个一次性代码,并将客户端重定向到一个由 NGINX Plus Ingress Controller 托管的特殊 URI (tokenEndPoint) ,然后使用一次性代码交换 JWT,供客户端在会话期间使用。
  3. NGINX Plus Ingress Controller 存储 JWT 并向客户端发送会话 cookie,其中包含对 JWT 的不透明引用。
  4. 当客户端发出后续请求并提供会话 cookie 时,NGINX Plus Ingress Controller 检索 JWT,并根据存储在 jwksURI URI 的证书加以验证。如果 JWT 有效且未过期,NGINX Ingress Controller 会将请求代理到适当的后端 Kubernetes pod。

除了支持默认的 openid 作用域外,NGINX Plus Ingress Controller OIDC 策略还支持标准的 OIDC 作用域作用域包括用户身份属性(例如姓名和电子邮件地址),它们可以用作访问控制标准。如果客户端和 IdP 都允许与 NGINX Plus Ingress Controller 共享这些作用域,那么它们的对应值在 IdP 的响应中被编码为 JWT 声明。

OIDC 策略一旦应用成功,它便可以在其他入向负载均衡配置中得到重复利用,从而简化向应用和 Kubernetes 服务添加身份验证和授权的过程。举例来说,您可以在 VirtualServer 对象中引用 OIDC 策略,并通过将 JWT 声明作为 HTTP 标头传递给上游应用来修改入向流量。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: webapp
spec:
  host: webapp.example.com
  tls:
    secret: tls-secret
    redirect:
      enable: true
  upstreams:
  - name: webapp
    service: webapp-svc
    port: 80
  routes:
  - path: /
    policies:
    - name: oidc-policy
    action:
      proxy:
        upstream: webapp
        resquestHeaders:
          pass: true
          set: 
          - name: My-Header 
            value: ${jwt_claim_profile}

1.10.0 版还有哪些新特性?

NGINX Ingress Controller 1.10.0 的推出延续了我们提供灵活、强大且易于使用的生产级 Ingress Controller 的承诺。NGINX Ingress Controller 可以配置 Kubernetes Ingress 资源和 NGINX Ingress 资源:

本节中的信息适用于 NGINX 开源版和 NGINX Plus Ingress Controller。

除了 OIDC 身份验证,1.10.0 版还提供了以下增强功能和改进功能:

  • 最新的 NGINX Service Mesh 集成——NGINX Service Mesh 0.8.0 版现已可供下载,并能够与 NGINX Ingress Controller 无缝集成。
  • 行为变更—— Policy 对象的apiVersion 已升级至 v1,且只有某些 secret 类型是有效的。
  • 增强的可视化和日志记录—— 额外的指标和日志注释可简化故障排除流程,帮助您快速发现痛点。
  • 其他新增特性——
    • 改进的注释和 secret 验证
    • 使用 NGINX App Protect 用户定义的签名拦截无法识别的威胁
    • IP 地址访问控制列表策略升级为生产就绪状态
    • Rancher RKE 支持

重要的行为变更

Policy 资源的 apiVersion 已升级至 v1(但相应的模式没有改变)。如果您使用版本 1.8.0 或 1.9.0 创建了策略,并计划继续使用它们,则请在更新后的 apiVersion 版本号下再次创建它们。有关详细信息,请参阅 版本说明中的 升级

NGINX Ingress Controller 目前只接受某些类型的 secret。 请参阅版本说明中的更新 secret

增强的可视化和日志

配置队列指标

监控对于实践中应用行为的理解和可视化至关重要。监控可以简化故障排除流程,查明应用中的缺陷和瓶颈,进而帮助您快速修复。

在该版本中,我们添加了新的 workqueue 指标 ,用于报告在任何给定时间下队列中正在等待的未完成的配置变更数量,以及配置在 NGINX Ingress Controller 队列中等待被处理的时间。

您可以使用这些指标来确定请求的配置变更是否过多,以及 NGINX Ingress Controller 是否拥有快速处、理配置所需的资源。

如果 Ingress Controller 无法处理大量的配置变更,您可以为当前部署的 NGINX Ingress Controller pod 分配更多的计算资源(CPU 和内存),或者增加部署的数量来分散要处理的配置数量。

日志注释(含 Kubernetes 对象名称)

1.9.0 版 为导出到 Prometheus 的 Ingress Controller 指标添加了注释 ,以指定 Kubernetes 服务名称、pod 和 Ingress 资源名称。

此版本为 NGINX Ingress Controller 日志添加了相同的注释。日志注释不仅可以提高可视性,而且还可以简化故障排除流程。操作人员现在可以将日志条目与特定的 Kubernetes 服务和资源(例如 Ingress 或VirtualServer 资源)相关联,以加快识别需要注意的 Kubernetes 对象。例如,连接可能会失败,因为 VirtualServer 资源不包括任何可用于服务连接的上游。

$ kubectl logs NGINX_Ingress_Controller_pod_name -n nginx-ingress
174.115.106.xxx - - [27/Jan/2021:21:36:50 +0000] "GET /tea HTTP/1.1" 503 154 "-"  "curl/7.54.0" "-" "app" "virtualserver" "default" "billing-svc"

此外,应用和服务所有者可以以服务名称或 Ingress 资源来过滤日志,以仅访问属于其应用的日志条目。这在早期版本中是不可能实现的,因为其日志条目未指定服务或 Ingress 资源。

要配置这项日志功能,请在 NGINX Ingress Controller ConfigMaplog-format字段添加内置变量

TCP 指标的注释

1.10.0 版还在导出到 Prometheus 的 TCP/UDP 指标中添加了关于 Kubernetes 服务名称、pod 和 Ingress 资源名称的注释。将 TCP 应用的性能与 Kubernetes 对象相关联可以简化故障排除流程。以下示例是一个关于上游服务器活动连接的带注释的 Prometheus 指标:

# HELP nginx_ingress_nginxplus_stream_upstream_server_active Active connections
# TYPE nginx_ingress_nginxplus_stream_upstream_server_active gauge
nginx_ingress_nginxplus_stream_upstream_server_active{class="nginx",pod_name="coredns-6b67b8f5d6-pnrwl",resource_name="dns-tcp",resource_namespace="default",resource_type="transportserver",server="10.0.2.20:5353",service="coredns",upstream="ts_default_dns-tcp_dns-app"} 3

其他特性

验证 Ingress 注释

Ingress资源中验证注释可防止 NGINX Ingress Controller 因无效注释 值而在重新加载过程中停机,从而提高 NGINX Ingress Controller 的可靠性。相比早期版本,1.10.0 版能够验证更多的注释。

NGINX Ingress Controller 现在还会在应用 Ingress manifest 后,立即报告与 Ingress 资源相关的事件 验证错误。使用kubectl describe命令可以立即看到错误消息,而不必在发生错误后查看日志文件。

$ kubectl describe ing cafe-ingress
... 
Events:
  Type     Reason          Age   From                      Message
  ----     ------          ----  ----                      -------
  Warning  Rejected        7s    nginx-ingress-controller  default/cafe-ingress was rejected: with error: annotations.nginx.org/lb-method: Invalid value: "least_cons": Invalid load balancing method: "least_cons"
... 

验证 Secret

NGINX Ingress Controller 1.10.0 可评估 Kubernetes secrets的内容,并通过防止停机或复杂的故障排除场景来提高可靠性。如果引用的 secret 无效或者不存在,NGINX Ingress Controller 会在与引用 secret 的资源相关的事件中报告该问题。

$ kubectl describe ing cafe
... 
Events:
  Type     Reason                     Age   From                      Message
  ----     ------                     ----  ----                      -------
  Warning  AddedOrUpdatedWithWarning  8s    nginx-ingress-controller  Configuration for default/cafe-ingress was added or updated; with warning(s): TLS secret cafe-secret is invalid: Failed to validate TLS cert and key: tls: failed to find any PEM data in key input
...

NGINX App Protect 用户定义的签名

当企业需要快速阻止威胁但又没有预先为这些威胁构建签名时,用户定义的签名就会大派用场。借助 NGINX Ingress Controller 1.10.0,您可以创建NGINX App Protect 用户定义的签名 来自定义您的七层安全策略。

在以前的版本中,您只能使用 F5 提供的预定义签名。在 1.10.0 版中,您可以创建定制签名,并使用偏移参数和正则表达式来阻止用户输入的特定字符串,并指定有关字符串位置和格式的复杂规则。例如,当发现漏洞时,您可以创建定制签名来规避漏洞,而不是更新整个签名数据库。

用户定义的签名很容易从其他 F5 WAF 产品移植到 NGINX Ingress Controller,这简化了所有平台和环境中安全方案的可管理性。

IP 地址访问控制列表策略可投入生产环境

作为 1.10.0 版的一部分,我们正在将 1.8.0 版中引入的 IP 地址访问控制列表 (accessControl) 策略升级到生产就绪状态( 1.9.0 版中引入的三个策略和本版中引入的 OIDC 策略仍处于预览模式)。

Rancher Kubernetes Engine 支持

1.10.0 版通过在 Rancher 的目录中提供 NGINX Ingress Controller,支持在 Rancher Kubernetes Engine (RKE) 上运行 NGINX Ingress Controller。您只需在目录的用户界面中点击几下,并输入几个参数,即可轻松安装 NGINX Ingress Controller。

资源

有关 1.10.0 版的完整变更日志,请查看版本说明

如欲试用 NGINX Plus NGINX Ingress Controller for Kubernetes 和 NGINX App Protect,请立即下载30 天免费试用版 或者联系我们讨论您的用例

如欲试用 NGINX 开源版 NGINX Ingress Controller,您可以获取源代码进行编译,或者从 DockerHub 下载预构建的容器。

Hero image
Kubernetes:
从测试到生产

通过多种流量管理工具提升弹性、可视性和安全性

关于作者

Amir Rawdat

解决方案工程师

Amir Rawdat 是 NGINX 的技术营销工程师,专门负责各种技术内容的撰写。他在计算机网络、计算机编程、故障排除和内容撰写方面拥有深厚的背景。此前,Amir 是诺基亚(Nokia)的客户应用工程师。

关于 F5 NGINX

F5, Inc. 是备受欢迎的开源软件 NGINX 背后的商业公司。我们为现代应用的开发和交付提供一整套技术。我们的联合解决方案弥合了 NetOps 和 DevOps 之间的横沟,提供从代码到用户的多云应用服务。访问 nginx-cn.net 了解更多相关信息。