Argo Workflows HTTPAuth 详解为 HTTP 制品与请求配置 Basic Auth、客户端证书与 OAuth2 认证【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址: https://gitcode.com/gh_mirrors/ar/argo-workflows本篇技术指南围绕 Argo WorkflowsKubernetes 工作流引擎中IoArgoprojWorkflowV1alpha1HTTPAuth这一 API 类型展开它定义了 HTTP 制品HTTP Artifact与 HTTP 模板HTTP Template在发起请求时的三种客户端认证方式Basic Auth、客户端证书Client Cert与 OAuth2。读完本文你将掌握HTTPAuth的完整字段结构、三种认证机制各自的 Secret 引用方式、Java SDK 中的对应模型以及如何在 Workflow YAML 中组合使用它们保护私有制品仓库与受保护接口。一、HTTPAuth 是什么HTTP 制品的认证承载结构在 Argo Workflows 中HTTPAuth是挂载在HTTPArtifact上的认证配置结构。它本身不直接对应一种认证协议而是把三种常见的 HTTP 客户端认证方式统一收纳在一个对象里由用户在 YAML 中按需选用其一或组合使用。从 Go 源码 pkg/apis/workflow/v1alpha1/workflow_types.go 可以看到其精确定义type HTTPAuth struct { ClientCert ClientCertAuth json:clientCert,omitempty protobuf:bytes,1,opt,nameclientCert OAuth2 OAuth2Auth json:oauth2,omitempty protobuf:bytes,2,opt,nameoauth2 BasicAuth BasicAuth json:basicAuth,omitempty protobuf:bytes,3,opt,namebasicAuth }HTTPAuth的载体是HTTPArtifact。同文件中HTTPArtifact的定义pkg/apis/workflow/v1alpha1/workflow_types.go表明一个 HTTP 制品需要指定url可选携带headers列表、auth认证对象以及用于流式上传重定向场景的saveStreamViaFiletype HTTPArtifact struct { // URL of the artifact URL string json:url protobuf:bytes,1,opt,nameurl // Headers are an optional list of headers to send with HTTP requests for artifacts Headers []Header json:headers,omitempty protobuf:bytes,2,rep,nameheaders // Auth contains information for client authentication Auth *HTTPAuth json:auth,omitempty protobuf:bytes,3,opt,nameauth SaveStreamViaFile bool json:saveStreamViaFile,omitempty protobuf:varint,4,opt,namesaveStreamViaFile }三者皆为可选optional也就是说一个 HTTP 制品可以完全不认证也可以通过auth字段挂载任意一种认证方案。HTTPAuth的字段全部使用 Kubernetes 的SecretKeySelector引用凭据而不是直接书写明文这是其安全设计的关键。属性总览继承自官方 API 文档本类型在 Java SDK 生成的 API 参考文档 sdks/java/client/docs/IoArgoprojWorkflowV1alpha1HTTPAuth.md 中定义如下属性NameTypeDescriptionNotesbasicAuthIoArgoprojWorkflowV1alpha1BasicAuthBasic 认证用户名/密码配置optionalclientCertIoArgoprojWorkflowV1alpha1ClientCertAuth客户端证书mTLS认证配置optionaloauth2IoArgoprojWorkflowV1alpha1OAuth2AuthOAuth2 客户端凭据模式认证配置optional二、basicAuth基于 Secret 的用户名密码认证basicAuth对应BasicAuth类型是最简单直接的 HTTP 认证方式适用于受用户名/密码保护的制品服务器如私有的 WebDAV、企业内部下载站点等。源码定义位于 pkg/apis/workflow/v1alpha1/workflow_types.go// BasicAuth describes the secret selectors required for basic authentication type BasicAuth struct { // UsernameSecret is the secret selector to the repository username UsernameSecret *apiv1.SecretKeySelector json:usernameSecret,omitempty protobuf:bytes,1,opt,nameusernameSecret // PasswordSecret is the secret selector to the repository password PasswordSecret *apiv1.SecretKeySelector json:passwordSecret,omitempty protobuf:bytes,2,opt,namepasswordSecret }两个字段都是SecretKeySelector分别指向 Kubernetes Secret 中存放用户名与密码的键字段类型说明usernameSecretio.kubernetes.client.openapi.models.V1SecretKeySelector指向 Secret 中保存用户名的键passwordSecretio.kubernetes.client.openapi.models.V1SecretKeySelector指向 Secret 中保存密码的键配置示例apiVersion: v1 kind: Secret metadata: name: http-basic-auth type: Opaque stringData: username: my-user password: my-password --- apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: http-auth-basic- spec: entrypoint: main templates: - name: main inputs: artifacts: - name: private-data path: /tmp/private-data http: url: https://repo.example.com/private/data.tar.gz auth: basicAuth: usernameSecret: name: http-basic-auth key: username passwordSecret: name: http-basic-auth key: password container: image: alpine:3.19 command: [sh, -c] args: [ls -l /tmp/private-data cat /tmp/private-data]执行器侧的实现印证在运行 Workflow 时执行器会把解析后的用户名/密码注入 HTTP 请求。以制品驱动 workflow/artifacts/http/http.go 为例其ArtifactDriver持有Username与Password两个字段在构造 GET 请求时通过 Go 标准库的req.SetBasicAuth(h.Username, h.Password)见该文件第 36、47 行写入Authorization: Basic ...头写制品PUT时在buildPutRequest中同样执行req.SetBasicAuth(...)第 107、119 行。这与HTTPAuth.BasicAuth的语义完全对应控制器负责从 Secret 解析出明文凭据并传入执行器执行器负责实际注入请求。三、clientCert双向 TLSmTLS客户端证书认证clientCert对应ClientCertAuth类型用于需要客户端出示证书的服务端即 mTLS 场景例如受企业内部 PKI 保护的对象存储或制品仓库。源码定义位于 pkg/apis/workflow/v1alpha1/workflow_types.go// ClientCertAuth holds necessary information for client authentication via certificates type ClientCertAuth struct { ClientCertSecret *apiv1.SecretKeySelector json:clientCertSecret,omitempty protobuf:bytes,1,opt,nameclientCertSecret ClientKeySecret *apiv1.SecretKeySelector json:clientKeySecret,omitempty protobuf:bytes,2,opt,nameclientKeySecret }字段类型说明clientCertSecretio.kubernetes.client.openapi.models.V1SecretKeySelector指向存放客户端证书通常为 PEM 格式tls.crt的 Secret 键clientKeySecretio.kubernetes.client.openapi.models.V1SecretKeySelector指向存放客户端私钥通常为 PEM 格式tls.key的 Secret 键配置示例apiVersion: v1 kind: Secret metadata: name: http-client-cert type: kubernetes.io/tls stringData: tls.crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- tls.key: | -----BEGIN PRIVATE KEY----- ... -----END PRIVATE KEY----- --- apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: http-auth-cert- spec: entrypoint: main templates: - name: main inputs: artifacts: - name: secured-data path: /tmp/secured-data http: url: https://mtls.example.com/artifacts/data.bin auth: clientCert: clientCertSecret: name: http-client-cert key: tls.crt clientKeySecret: name: http-client-cert key: tls.key container: image: alpine:3.19 command: [sh, -c] args: [sha256sum /tmp/secured-data]实践提示证书与私钥最好使用kubernetes.io/tls类型 Secret 或 Base64 编码存放避免stringData在资源清单中明文暴露私钥生产环境应通过外部 Secret 管理方案如 Sealed Secrets、Vault注入。四、oauth2客户端凭据模式Client Credentials令牌认证oauth2对应OAuth2Auth类型用于需要先从 OAuth2 令牌端点换取 Access Token、再携带 Token 访问受保护资源的场景。其语义对应 OAuth2 的 Client Credentials 流程客户端用client_idclient_secret换取令牌适合机器与机器之间的服务认证。源码定义位于 pkg/apis/workflow/v1alpha1/workflow_types.go// OAuth2Auth holds all information for client authentication via OAuth2 tokens type OAuth2Auth struct { ClientIDSecret *apiv1.SecretKeySelector json:clientIDSecret,omitempty protobuf:bytes,1,opt,nameclientIDSecret ClientSecretSecret *apiv1.SecretKeySelector json:clientSecretSecret,omitempty protobuf:bytes,2,opt,nameclientSecretSecret TokenURLSecret *apiv1.SecretKeySelector json:tokenURLSecret,omitempty protobuf:bytes,3,opt,nametokenURLSecret Scopes []string json:scopes,omitempty protobuf:bytes,5,rep,namescopes EndpointParams []OAuth2EndpointParam json:endpointParams,omitempty protobuf:bytes,6,rep,nameendpointParams } // OAuth2EndpointParam is an optional field that should be sent in the OAuth request. type OAuth2EndpointParam struct { // Name is the header name Key string json:key protobuf:bytes,1,opt,namekey // Value is the literal value to use for the header Value string json:value,omitempty protobuf:bytes,2,opt,namevalue }对应 Java SDK 文档 sdks/java/client/docs/IoArgoprojWorkflowV1alpha1OAuth2Auth.md 中的属性如下NameTypeDescriptionNotesclientIDSecretio.kubernetes.client.openapi.models.V1SecretKeySelectorOAuth2 客户端 ID从 Secret 引用optionalclientSecretSecretio.kubernetes.client.openapi.models.V1SecretKeySelectorOAuth2 客户端密钥从 Secret 引用optionalendpointParamsListIoArgoprojWorkflowV1alpha1OAuth2EndpointParam附加到令牌请求中的额外表单参数optionalscopesListString请求令牌时申请的 scope 列表optionaltokenURLSecretio.kubernetes.client.openapi.models.V1SecretKeySelectorOAuth2 令牌端点 URL从 Secret 引用optional字段逐项说明clientIDSecretSecretKeySelector指向 Secret 中保存 OAuth2 客户端 ID 的键clientSecretSecretSecretKeySelector指向 Secret 中保存客户端密钥的键用于向令牌端点换取 TokentokenURLSecretSecretKeySelector指向 Secret 中保存令牌端点完整 URL 的键如https://auth.example.com/oauth2/tokenscopes字符串数组声明令牌请求中携带的权限范围如[read:artifacts, openid]endpointParamsOAuth2EndpointParam数组每个元素是key/value键值对作为额外表单参数随令牌请求发出——可用于传递audience、resource等 OAuth2 服务器要求的自定义参数。配置示例apiVersion: v1 kind: Secret metadata: name: http-oauth2 type: Opaque stringData: client-id: my-client client-secret: my-client-secret token-url: https://auth.example.com/oauth2/token --- apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: http-auth-oauth2- spec: entrypoint: main templates: - name: main inputs: artifacts: - name: oauth-protected path: /tmp/oauth-protected http: url: https://api.example.com/files/report.pdf auth: oauth2: clientIDSecret: name: http-oauth2 key: client-id clientSecretSecret: name: http-oauth2 key: client-secret tokenURLSecret: name: http-oauth2 key: token-url scopes: - read:files endpointParams: - key: audience value: artifacts-api container: image: alpine:3.19 command: [sh, -c] args: [cat /tmp/oauth-protected]该流程的执行语义是控制器从上述 Secret 中解析出客户端凭据与令牌端点向tokenURL发起application/x-www-form-urlencoded的令牌请求携带grant_typeclient_credentials、client_id、client_secret、scopes及endpointParams换取 Access Token 后将Authorization: Bearer token附加到后续对制品 URL 的请求上。五、三种认证方式的选用对比维度basicAuthclientCertoauth2凭据形式用户名 密码客户端证书 私钥客户端 ID 密钥换取 Bearer TokenSecret 引用数2usernameSecret、passwordSecret2clientCertSecret、clientKeySecret3 个 Secret 引用 2 个可选列表scopes、endpointParams典型场景私有 WebDAV、基础认证网关mTLS 企业内网服务、PKI 受保护仓库OAuth2 保护的 API 与云服务OIDC 资源服务器传输安全凭据经 Base64 编码建议配合 HTTPSTLS 层完成握手认证安全性最高Token 经 HTTPS 传输可附带过期与 scope 控制选择建议能够使用 mTLS 的环境优先使用clientCert需要令牌级授权、刷新与 scope 控制的场景选择oauth2最简单的用户名密码保护选择basicAuth。三者不是互斥的字段冲突设计但实际请求中同时启用多种认证可能引发服务端歧义建议按需只启用一种。六、组合使用与常见注意事项与静态 Header 的配合HTTPAuth只负责认证而自定义请求头由HTTPArtifact.headers承载。Header类型定义于 pkg/apis/workflow/v1alpha1/workflow_types.go// Header indicate a key-value request header to be used when fetching artifacts over HTTP type Header struct { // Name is the header name Name string json:name protobuf:bytes,1,opt,namename // Value is the literal value to use for the header Value string json:value protobuf:bytes,2,opt,namevalue }在 Java SDK 中对应 IoArgoprojWorkflowV1alpha1Header包含name与value两个字段。例如需要额外的X-Api-Key头时http: url: https://repo.example.com/data.txt headers: - name: X-Api-Key value: abc123 auth: basicAuth: usernameSecret: { name: http-basic-auth, key: username } passwordSecret: { name: http-basic-auth, key: password }执行器在 workflow/artifacts/http/http.go 的retrieveContent第 43-45 行与buildPutRequest第 115-117 行中遍历inputArtifact.HTTP.Headers逐项req.Header.Add(...)与认证头共同生效。安全注意要点一律通过 Secret 引用HTTPAuth的所有敏感字段用户名、密码、客户端 ID、密钥、令牌端点、证书与私钥都设计为SecretKeySelector严禁把凭据明文写入 Workflow YAMLSecret 本身应避免使用明文stringData提交到 Git推荐用 Sealed Secrets、External Secrets 或 Vault 注入优先 HTTPSBasic Auth 凭据仅做 Base64 编码而非加密必须配合 TLS 传输OAuth2 Token 与客户端证书同样应在 HTTPS 之上使用令牌端点 URL 也走 SecrettokenURLSecret表明 URL 本身被视为敏感配置这便于不同环境开发/生产复用同一份 Workflow 模板而动态切换认证端点证书私钥权限tls.key所在的 Secret 应通过 RBAC 限制可读取的 ServiceAccount避免工作流任意模板读取到私钥。可进一步阅读的仓库参考HTTP 制品类型的完整 Java SDK 模型IoArgoprojWorkflowV1alpha1HTTPArtifact三种认证子类型的 Java SDK 文档IoArgoprojWorkflowV1alpha1BasicAuth、IoArgoprojWorkflowV1alpha1ClientCertAuth、IoArgoprojWorkflowV1alpha1OAuth2AuthGo API 类型定义pkg/apis/workflow/v1alpha1/workflow_types.go运行时制品驱动实现workflow/artifacts/http/http.go可运行的 HTTP 输入制品示例examples/input-artifact-http.yamlHTTP 模板HTTP Template的认证与超时配置参考workflow/controller/http_template.go七、总结IoArgoprojWorkflowV1alpha1HTTPAuth是 Argo Workflows 为 HTTP 制品与 HTTP 请求提供的统一认证配置入口通过basicAuth、clientCert、oauth2三个可选字段覆盖了用户名密码、mTLS 与 OAuth2 客户端凭据三类主流认证协议。其所有凭据均以SecretKeySelector形式引用 Kubernetes Secret兼顾了安全性与多环境可移植性执行器侧workflow/artifacts/http/http.go在构造 GET/PUT 请求时注入Authorization头完成实际认证。无论你的制品托管在 Basic Auth 保护的 WebDAV、要求客户端证书的企业内网还是 OAuth2 保护的云 API 之后都可以通过一个auth字段在工作流中安全地拉取与上传制品。【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址: https://gitcode.com/gh_mirrors/ar/argo-workflows创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Argo Workflows HTTPAuth 详解：为 HTTP 制品与请求配置 Basic Auth、客户端证书与 OAuth2 认证
Argo Workflows HTTPAuth 详解为 HTTP 制品与请求配置 Basic Auth、客户端证书与 OAuth2 认证【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址: https://gitcode.com/gh_mirrors/ar/argo-workflows本篇技术指南围绕 Argo WorkflowsKubernetes 工作流引擎中IoArgoprojWorkflowV1alpha1HTTPAuth这一 API 类型展开它定义了 HTTP 制品HTTP Artifact与 HTTP 模板HTTP Template在发起请求时的三种客户端认证方式Basic Auth、客户端证书Client Cert与 OAuth2。读完本文你将掌握HTTPAuth的完整字段结构、三种认证机制各自的 Secret 引用方式、Java SDK 中的对应模型以及如何在 Workflow YAML 中组合使用它们保护私有制品仓库与受保护接口。一、HTTPAuth 是什么HTTP 制品的认证承载结构在 Argo Workflows 中HTTPAuth是挂载在HTTPArtifact上的认证配置结构。它本身不直接对应一种认证协议而是把三种常见的 HTTP 客户端认证方式统一收纳在一个对象里由用户在 YAML 中按需选用其一或组合使用。从 Go 源码 pkg/apis/workflow/v1alpha1/workflow_types.go 可以看到其精确定义type HTTPAuth struct { ClientCert ClientCertAuth json:clientCert,omitempty protobuf:bytes,1,opt,nameclientCert OAuth2 OAuth2Auth json:oauth2,omitempty protobuf:bytes,2,opt,nameoauth2 BasicAuth BasicAuth json:basicAuth,omitempty protobuf:bytes,3,opt,namebasicAuth }HTTPAuth的载体是HTTPArtifact。同文件中HTTPArtifact的定义pkg/apis/workflow/v1alpha1/workflow_types.go表明一个 HTTP 制品需要指定url可选携带headers列表、auth认证对象以及用于流式上传重定向场景的saveStreamViaFiletype HTTPArtifact struct { // URL of the artifact URL string json:url protobuf:bytes,1,opt,nameurl // Headers are an optional list of headers to send with HTTP requests for artifacts Headers []Header json:headers,omitempty protobuf:bytes,2,rep,nameheaders // Auth contains information for client authentication Auth *HTTPAuth json:auth,omitempty protobuf:bytes,3,opt,nameauth SaveStreamViaFile bool json:saveStreamViaFile,omitempty protobuf:varint,4,opt,namesaveStreamViaFile }三者皆为可选optional也就是说一个 HTTP 制品可以完全不认证也可以通过auth字段挂载任意一种认证方案。HTTPAuth的字段全部使用 Kubernetes 的SecretKeySelector引用凭据而不是直接书写明文这是其安全设计的关键。属性总览继承自官方 API 文档本类型在 Java SDK 生成的 API 参考文档 sdks/java/client/docs/IoArgoprojWorkflowV1alpha1HTTPAuth.md 中定义如下属性NameTypeDescriptionNotesbasicAuthIoArgoprojWorkflowV1alpha1BasicAuthBasic 认证用户名/密码配置optionalclientCertIoArgoprojWorkflowV1alpha1ClientCertAuth客户端证书mTLS认证配置optionaloauth2IoArgoprojWorkflowV1alpha1OAuth2AuthOAuth2 客户端凭据模式认证配置optional二、basicAuth基于 Secret 的用户名密码认证basicAuth对应BasicAuth类型是最简单直接的 HTTP 认证方式适用于受用户名/密码保护的制品服务器如私有的 WebDAV、企业内部下载站点等。源码定义位于 pkg/apis/workflow/v1alpha1/workflow_types.go// BasicAuth describes the secret selectors required for basic authentication type BasicAuth struct { // UsernameSecret is the secret selector to the repository username UsernameSecret *apiv1.SecretKeySelector json:usernameSecret,omitempty protobuf:bytes,1,opt,nameusernameSecret // PasswordSecret is the secret selector to the repository password PasswordSecret *apiv1.SecretKeySelector json:passwordSecret,omitempty protobuf:bytes,2,opt,namepasswordSecret }两个字段都是SecretKeySelector分别指向 Kubernetes Secret 中存放用户名与密码的键字段类型说明usernameSecretio.kubernetes.client.openapi.models.V1SecretKeySelector指向 Secret 中保存用户名的键passwordSecretio.kubernetes.client.openapi.models.V1SecretKeySelector指向 Secret 中保存密码的键配置示例apiVersion: v1 kind: Secret metadata: name: http-basic-auth type: Opaque stringData: username: my-user password: my-password --- apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: http-auth-basic- spec: entrypoint: main templates: - name: main inputs: artifacts: - name: private-data path: /tmp/private-data http: url: https://repo.example.com/private/data.tar.gz auth: basicAuth: usernameSecret: name: http-basic-auth key: username passwordSecret: name: http-basic-auth key: password container: image: alpine:3.19 command: [sh, -c] args: [ls -l /tmp/private-data cat /tmp/private-data]执行器侧的实现印证在运行 Workflow 时执行器会把解析后的用户名/密码注入 HTTP 请求。以制品驱动 workflow/artifacts/http/http.go 为例其ArtifactDriver持有Username与Password两个字段在构造 GET 请求时通过 Go 标准库的req.SetBasicAuth(h.Username, h.Password)见该文件第 36、47 行写入Authorization: Basic ...头写制品PUT时在buildPutRequest中同样执行req.SetBasicAuth(...)第 107、119 行。这与HTTPAuth.BasicAuth的语义完全对应控制器负责从 Secret 解析出明文凭据并传入执行器执行器负责实际注入请求。三、clientCert双向 TLSmTLS客户端证书认证clientCert对应ClientCertAuth类型用于需要客户端出示证书的服务端即 mTLS 场景例如受企业内部 PKI 保护的对象存储或制品仓库。源码定义位于 pkg/apis/workflow/v1alpha1/workflow_types.go// ClientCertAuth holds necessary information for client authentication via certificates type ClientCertAuth struct { ClientCertSecret *apiv1.SecretKeySelector json:clientCertSecret,omitempty protobuf:bytes,1,opt,nameclientCertSecret ClientKeySecret *apiv1.SecretKeySelector json:clientKeySecret,omitempty protobuf:bytes,2,opt,nameclientKeySecret }字段类型说明clientCertSecretio.kubernetes.client.openapi.models.V1SecretKeySelector指向存放客户端证书通常为 PEM 格式tls.crt的 Secret 键clientKeySecretio.kubernetes.client.openapi.models.V1SecretKeySelector指向存放客户端私钥通常为 PEM 格式tls.key的 Secret 键配置示例apiVersion: v1 kind: Secret metadata: name: http-client-cert type: kubernetes.io/tls stringData: tls.crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- tls.key: | -----BEGIN PRIVATE KEY----- ... -----END PRIVATE KEY----- --- apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: http-auth-cert- spec: entrypoint: main templates: - name: main inputs: artifacts: - name: secured-data path: /tmp/secured-data http: url: https://mtls.example.com/artifacts/data.bin auth: clientCert: clientCertSecret: name: http-client-cert key: tls.crt clientKeySecret: name: http-client-cert key: tls.key container: image: alpine:3.19 command: [sh, -c] args: [sha256sum /tmp/secured-data]实践提示证书与私钥最好使用kubernetes.io/tls类型 Secret 或 Base64 编码存放避免stringData在资源清单中明文暴露私钥生产环境应通过外部 Secret 管理方案如 Sealed Secrets、Vault注入。四、oauth2客户端凭据模式Client Credentials令牌认证oauth2对应OAuth2Auth类型用于需要先从 OAuth2 令牌端点换取 Access Token、再携带 Token 访问受保护资源的场景。其语义对应 OAuth2 的 Client Credentials 流程客户端用client_idclient_secret换取令牌适合机器与机器之间的服务认证。源码定义位于 pkg/apis/workflow/v1alpha1/workflow_types.go// OAuth2Auth holds all information for client authentication via OAuth2 tokens type OAuth2Auth struct { ClientIDSecret *apiv1.SecretKeySelector json:clientIDSecret,omitempty protobuf:bytes,1,opt,nameclientIDSecret ClientSecretSecret *apiv1.SecretKeySelector json:clientSecretSecret,omitempty protobuf:bytes,2,opt,nameclientSecretSecret TokenURLSecret *apiv1.SecretKeySelector json:tokenURLSecret,omitempty protobuf:bytes,3,opt,nametokenURLSecret Scopes []string json:scopes,omitempty protobuf:bytes,5,rep,namescopes EndpointParams []OAuth2EndpointParam json:endpointParams,omitempty protobuf:bytes,6,rep,nameendpointParams } // OAuth2EndpointParam is an optional field that should be sent in the OAuth request. type OAuth2EndpointParam struct { // Name is the header name Key string json:key protobuf:bytes,1,opt,namekey // Value is the literal value to use for the header Value string json:value,omitempty protobuf:bytes,2,opt,namevalue }对应 Java SDK 文档 sdks/java/client/docs/IoArgoprojWorkflowV1alpha1OAuth2Auth.md 中的属性如下NameTypeDescriptionNotesclientIDSecretio.kubernetes.client.openapi.models.V1SecretKeySelectorOAuth2 客户端 ID从 Secret 引用optionalclientSecretSecretio.kubernetes.client.openapi.models.V1SecretKeySelectorOAuth2 客户端密钥从 Secret 引用optionalendpointParamsListIoArgoprojWorkflowV1alpha1OAuth2EndpointParam附加到令牌请求中的额外表单参数optionalscopesListString请求令牌时申请的 scope 列表optionaltokenURLSecretio.kubernetes.client.openapi.models.V1SecretKeySelectorOAuth2 令牌端点 URL从 Secret 引用optional字段逐项说明clientIDSecretSecretKeySelector指向 Secret 中保存 OAuth2 客户端 ID 的键clientSecretSecretSecretKeySelector指向 Secret 中保存客户端密钥的键用于向令牌端点换取 TokentokenURLSecretSecretKeySelector指向 Secret 中保存令牌端点完整 URL 的键如https://auth.example.com/oauth2/tokenscopes字符串数组声明令牌请求中携带的权限范围如[read:artifacts, openid]endpointParamsOAuth2EndpointParam数组每个元素是key/value键值对作为额外表单参数随令牌请求发出——可用于传递audience、resource等 OAuth2 服务器要求的自定义参数。配置示例apiVersion: v1 kind: Secret metadata: name: http-oauth2 type: Opaque stringData: client-id: my-client client-secret: my-client-secret token-url: https://auth.example.com/oauth2/token --- apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: http-auth-oauth2- spec: entrypoint: main templates: - name: main inputs: artifacts: - name: oauth-protected path: /tmp/oauth-protected http: url: https://api.example.com/files/report.pdf auth: oauth2: clientIDSecret: name: http-oauth2 key: client-id clientSecretSecret: name: http-oauth2 key: client-secret tokenURLSecret: name: http-oauth2 key: token-url scopes: - read:files endpointParams: - key: audience value: artifacts-api container: image: alpine:3.19 command: [sh, -c] args: [cat /tmp/oauth-protected]该流程的执行语义是控制器从上述 Secret 中解析出客户端凭据与令牌端点向tokenURL发起application/x-www-form-urlencoded的令牌请求携带grant_typeclient_credentials、client_id、client_secret、scopes及endpointParams换取 Access Token 后将Authorization: Bearer token附加到后续对制品 URL 的请求上。五、三种认证方式的选用对比维度basicAuthclientCertoauth2凭据形式用户名 密码客户端证书 私钥客户端 ID 密钥换取 Bearer TokenSecret 引用数2usernameSecret、passwordSecret2clientCertSecret、clientKeySecret3 个 Secret 引用 2 个可选列表scopes、endpointParams典型场景私有 WebDAV、基础认证网关mTLS 企业内网服务、PKI 受保护仓库OAuth2 保护的 API 与云服务OIDC 资源服务器传输安全凭据经 Base64 编码建议配合 HTTPSTLS 层完成握手认证安全性最高Token 经 HTTPS 传输可附带过期与 scope 控制选择建议能够使用 mTLS 的环境优先使用clientCert需要令牌级授权、刷新与 scope 控制的场景选择oauth2最简单的用户名密码保护选择basicAuth。三者不是互斥的字段冲突设计但实际请求中同时启用多种认证可能引发服务端歧义建议按需只启用一种。六、组合使用与常见注意事项与静态 Header 的配合HTTPAuth只负责认证而自定义请求头由HTTPArtifact.headers承载。Header类型定义于 pkg/apis/workflow/v1alpha1/workflow_types.go// Header indicate a key-value request header to be used when fetching artifacts over HTTP type Header struct { // Name is the header name Name string json:name protobuf:bytes,1,opt,namename // Value is the literal value to use for the header Value string json:value protobuf:bytes,2,opt,namevalue }在 Java SDK 中对应 IoArgoprojWorkflowV1alpha1Header包含name与value两个字段。例如需要额外的X-Api-Key头时http: url: https://repo.example.com/data.txt headers: - name: X-Api-Key value: abc123 auth: basicAuth: usernameSecret: { name: http-basic-auth, key: username } passwordSecret: { name: http-basic-auth, key: password }执行器在 workflow/artifacts/http/http.go 的retrieveContent第 43-45 行与buildPutRequest第 115-117 行中遍历inputArtifact.HTTP.Headers逐项req.Header.Add(...)与认证头共同生效。安全注意要点一律通过 Secret 引用HTTPAuth的所有敏感字段用户名、密码、客户端 ID、密钥、令牌端点、证书与私钥都设计为SecretKeySelector严禁把凭据明文写入 Workflow YAMLSecret 本身应避免使用明文stringData提交到 Git推荐用 Sealed Secrets、External Secrets 或 Vault 注入优先 HTTPSBasic Auth 凭据仅做 Base64 编码而非加密必须配合 TLS 传输OAuth2 Token 与客户端证书同样应在 HTTPS 之上使用令牌端点 URL 也走 SecrettokenURLSecret表明 URL 本身被视为敏感配置这便于不同环境开发/生产复用同一份 Workflow 模板而动态切换认证端点证书私钥权限tls.key所在的 Secret 应通过 RBAC 限制可读取的 ServiceAccount避免工作流任意模板读取到私钥。可进一步阅读的仓库参考HTTP 制品类型的完整 Java SDK 模型IoArgoprojWorkflowV1alpha1HTTPArtifact三种认证子类型的 Java SDK 文档IoArgoprojWorkflowV1alpha1BasicAuth、IoArgoprojWorkflowV1alpha1ClientCertAuth、IoArgoprojWorkflowV1alpha1OAuth2AuthGo API 类型定义pkg/apis/workflow/v1alpha1/workflow_types.go运行时制品驱动实现workflow/artifacts/http/http.go可运行的 HTTP 输入制品示例examples/input-artifact-http.yamlHTTP 模板HTTP Template的认证与超时配置参考workflow/controller/http_template.go七、总结IoArgoprojWorkflowV1alpha1HTTPAuth是 Argo Workflows 为 HTTP 制品与 HTTP 请求提供的统一认证配置入口通过basicAuth、clientCert、oauth2三个可选字段覆盖了用户名密码、mTLS 与 OAuth2 客户端凭据三类主流认证协议。其所有凭据均以SecretKeySelector形式引用 Kubernetes Secret兼顾了安全性与多环境可移植性执行器侧workflow/artifacts/http/http.go在构造 GET/PUT 请求时注入Authorization头完成实际认证。无论你的制品托管在 Basic Auth 保护的 WebDAV、要求客户端证书的企业内网还是 OAuth2 保护的云 API 之后都可以通过一个auth字段在工作流中安全地拉取与上传制品。【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址: https://gitcode.com/gh_mirrors/ar/argo-workflows创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考