如何在nginx Ingress中用K8s Secret替代硬编码值设置HTTP认证头

整体实现思路 #

把原配置中硬编码在Ingress注解里的客户端认证串（Base64编码的client_id:client_secret），从Ingress资源中剥离，迁移到K8s原生Secret资源中托管，在Ingress的认证片段配置中动态读取该值，既保证和原有硬编码配置的功能完全等价，又避免敏感信息泄露，满足集群内部的接口访问安全要求。 #

具体配置步骤 #

1. 创建存储客户端认证凭证的Secret #

将原本硬编码的authheaderhere==对应的值，写入集群内的Secret资源，不要直接写入Ingress定义：

kubectl create secret generic jwt-introspect-client-cred \
  --from-literal=auth-header='这里替换成实际的Base64编码认证串' \
  -n 你的Ingress资源所在的命名空间

Secret创建完成后，配置RBAC权限做最小化访问管控：仅授权nginx-ingress-controller对应的服务账号拥有该Secret的读取权限，其他集群用户、服务账号默认无访问权限。

2. 按场景选择适配的免硬编码配置方案 #

方案一：Ingress配置内动态读取Secret值（通用推荐）

该方案适配nginx-ingress 1.11及以上版本，不需要额外修改nginx-ingress-controller的Deployment配置，直接在Ingress的auth-snippet注解中，利用nginx-ingress内置的模板能力，动态查询Secret中的凭证值。
替换原有的硬编码auth-snippet配置为如下内容：

nginx.ingress.kubernetes.io/auth-snippet: |
  proxy_set_header auth-header "{{ $secret := (lookup "v1" "Secret" "你的Ingress命名空间" "jwt-introspect-client-cred") }}{{ index $secret.data "auth-header" | b64dec }}";

配置说明：

• 模板内置的lookup函数会在nginx配置重载时，实时从集群中拉取对应Secret的内容，自动完成Base64解码后填充到请求头中，逻辑和硬编码完全一致
• 因为真实凭证值完全存储在Secret中，Ingress定义中不会暴露任何敏感信息，即使有用户能查看Ingress资源详情，也无法拿到实际的客户端密钥
• 后续Secret中的凭证更新时，只要触发一次Ingress配置重载即可生效，不需要修改Ingress资源本身

方案二：通过Ingress控制器环境变量注入凭证（多Ingress复用场景）

如果当前集群中有多个Ingress都需要调用同一个JWT内省端点，可将Secret以环境变量的形式挂载到nginx-ingress-controller的Pod中，复用统一的凭证配置。
操作步骤：

1. 修改nginx-ingress-controller的Deployment配置，在容器环境变量段追加Secret的引用：

   # 路径：spec.containers[nginx-ingress-controller].env
   - name: INTROSPECT_AUTH_HEADER
     valueFrom:
       secretKeyRef:
         name: jwt-introspect-client-cred
         key: auth-header
   

2. 修改对应Ingress的auth-snippet注解，直接引用环境变量值，不需要硬编码：

   nginx.ingress.kubernetes.io/auth-snippet: |
     proxy_set_header auth-header "$INTROSPECT_AUTH_HEADER";
   

配套安全强化配置 #

为了满足“内省端点即使在集群内部也仅响应携带有效认证的请求”的要求，需要配套调整两点规则：

• 不要将存储客户端凭证的Secret挂载到JWT内省服务的Pod中，内省服务只需内置存储的客户端密钥做比对校验即可，避免凭证过度扩散
• 禁止将包含凭证值的Secret纳入Git仓库管理，所有凭证的更新、轮换流程独立走密钥管理通道完成

内容的提问来源于stack exchange，提问作者tech4242