ZenML Azure Service Connector 深度指南：统一认证 Blob 存储、AKS 集群与 ACR 容器仓库

ZenML Azure Service Connector 深度指南：统一认证 Blob 存储、AKS 集群与 ACR 容器仓库

发布时间：2026/9/19 18:39:09
ZenML Azure Service Connector 深度指南：统一认证 Blob 存储、AKS 集群与 ACR 容器仓库 ZenML Azure Service Connector 深度指南统一认证 Blob 存储、AKS 集群与 ACR 容器仓库【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml本文基于 ZenML 开源仓库的 Azure Service Connector 官方文档 及 源码实现系统讲解如何在 ZenML 中通过一个 Azure Service Connector 完成对 Azure Blob 存储容器、AKS Kubernetes 集群、ACR 容器仓库及任意 Azure 服务的统一认证与访问。读完本文你将掌握该连接器的资源类型与命名规范、三种认证方法隐式认证、服务主体、访问令牌的适用场景与配置命令并能够将 Artifact Store、Kubernetes Orchestrator、Container Registry 等 Stack Components 一键连接到 Azure 资源同时理解其底层源码实现原理。概述一个连接器打通全部 Azure 资源ZenML Azure Service Connector 负责封装对 Azure 托管服务与资源的认证和访问覆盖的资源包括Azure Blob 存储容器blob storage containersACR 容器仓库ACR repositoriesAKS Kubernetes 集群AKS clusters该连接器支持自动配置与凭据探测可以从本机已配置好的 Azure CLI 中直接提取配置与凭据。它既是一个通用的 Azure 访问入口向客户端签发可用于创建任意 Azure Python 客户端的凭据也能为 Azure Blob 存储、Docker 和 Kubernetes Python 客户端提供专门的认证处理同时还允许为本地 Docker 与 Kubernetes CLI 下发配置。在源码层面连接器的类型规格定义于 azure_service_connector.py其连接器类型标识为azure资源类型常量和集成声明则位于 src/zenml/integrations/azure/init.pyAZURE_CONNECTOR_TYPE azure、AZURE_RESOURCE_TYPE azure-generic、BLOB_RESOURCE_TYPE blob-container。在已安装 Azure 集成后可以通过以下命令查看该连接器类型的完整能力矩阵$ zenml service-connector list-types --type azure┏━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━┯━━━━━━━┯━━━━━━━━┓ ┃ NAME │ TYPE │ RESOURCE TYPES │ AUTH METHODS │ LOCAL │ REMOTE ┃ ┠─────────────────────────┼──────────┼───────────────────────┼───────────────────┼───────┼────────┨ ┃ Azure Service Connector │ azure │ azure-generic │ implicit │ ✅ │ ✅ ┃ ┃ │ │ blob-container │ service-principal │ │ ┃ ┃ │ │ kubernetes-cluster │ access-token │ │ ┃ ┃ │ │ docker-registry │ │ │ ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━┷━━━━━━━┷━━━━━━━━┛LOCAL与REMOTE两列表示该连接器类型在本地ZenML 客户端与管道运行处和远端ZenML Server 运行处的可用性关于本地/远端可用性对可执行操作的影响可参见完整指南。快速上手安装与先决条件Azure Service Connector 属于 Azure ZenML 集成的一部分有两种安装方式pip install zenml[connectors-azure]—— 仅安装 Azure Service Connector 类型所需的 Python 依赖zenml integration install azure—— 安装完整的 Azure ZenML 集成。从源码看Azure 集成的依赖清单定义在 src/zenml/integrations/azure/init.py核心包括adlfs、azure-identity、azure-mgmt-containerregistry、azure-mgmt-containerservice、azure-mgmt-storage、azure-mgmt-resource、azure-storage-blob、kubernetes等。需要特别说明的是本机并不要求预先安装并配置 Azure CLI才能用该连接器将 Stack Components 连接到 Azure 资源。但如果希望快速使用自动配置auto-configuration特性则建议预先通过az login配置好 Azure CLI 凭据。提示自动配置方案仅能获取临时访问令牌而临时令牌无法用于 Azure Blob 存储资源。因此要充分发挥 Azure Service Connector 的能力官方建议创建并配置一个 Azure 服务主体service principal及其凭据原文链接此处不再赘述外部地址。资源类型四种访问粒度Generic Azure 资源azure-generic该资源类型允许 Stack Components 借助连接器访问任意 Azure 服务或资源。被使用时Stack Components 会获得通用的 azure-identity 凭据可用于为任何特定的 Azure 服务创建 Azure Python 客户端。它适用于那些没有专属资源类型如 Blob 容器、Kubernetes 集群、Docker 仓库对应的 Stack Components使用时应配合一组匹配的 Azure 权限以允许访问 Stack Components 所需的远程资源集合。该资源类型的资源名Resource Name表示连接器被授权访问的Azure 订阅subscription名称。从源码看azure-generic类型不支持配置具体的资源实例supports_instancesFalse见 azure_service_connector.py其默认资源 ID 直接取自订阅名称_get_default_resource_id而在_connect_to_resource中该类型直接向客户端返回 AzureTokenCredential对象源码位置。Azure Blob 存储容器blob-container该资源类型允许用户连接 Azure Blob 容器。被使用时Stack Components 会获得一个预配置好的 Azure Blob Storage 客户端源码中即BlobServiceClient见 azure_service_connector.py。配置的凭据必须至少拥有与目标存储账户或容器相关联的以下 Azure IAM 权限允许对 blob 进行读写例如Storage Blob Data Contributor角色允许列出存储账户例如Reader and Data Access角色——仅当连接器中未配置存储账户时需要允许列出存储账户中的容器例如Reader and Data Access角色。资源名若设置必须采用以下两种格式之一标识 Azure Blob 容器Azure Blob 容器 URI规范资源名{az|abfs}://{container-name}Azure Blob 容器名{container-name}访问范围的收窄遵循如下规则若连接器中配置了存储账户则只可访问该存储账户中的 Blob 容器否则若连接器中配置了资源组则只可访问该资源组内存储账户中的 Blob 容器若两者都未配置则可访问所有可达存储账户中的所有 Blob 容器。警告与 Azure Blob 存储资源兼容的认证方法**只有隐式认证implicit与服务主体认证service-principal**两种。在源码中资源 ID 的解析由_parse_blob_container_resource_id完成azure_service_connector.py正则要求容器名符合 Azure 命名规范363 位小写字母、数字、连字符不能含连续--容器的枚举与存储账户定位逻辑实现在_list_blob_containers。此外_verify方法中明确拒绝了access-token认证方法用于 blob 存储资源源码位置与文档警告完全一致。AKS Kubernetes 集群kubernetes-cluster该资源类型允许 Stack Components 像访问标准 Kubernetes 集群一样访问 AKS 集群。被使用时Stack Components 会获得一个预认证的 python-kubernetes 客户端实例。配置的凭据必须至少拥有与目标 AKS 集群相关的以下 Azure IAM 权限允许列出 AKS 集群并获取其凭据例如Azure Kubernetes Service Cluster Admin Role角色。资源名若设置必须采用以下两种格式之一标识 AKS 集群资源组限定的 AKS 集群名规范格式[{resource-group}/]{cluster-name}AKS 集群名{cluster-name}由于 AKS 集群名在资源组内唯一可以在资源名中加入资源组以避免歧义。若连接器中已配置资源组则资源名中的资源组必须与之一致若连接器中未配置资源组、资源名中也未包含资源组连接器将尝试在任意资源组中查找该集群。若连接器中配置了资源组则只可访问该资源组内的 AKS 集群。源码中的解析逻辑_parse_aks_resource_id见 azure_service_connector.py支持上述两种格式并会校验资源组一致性在_get_connector_client中连接器通过ContainerServiceClient拉取 AKS 集群的 admin kubeconfig再将其转换为一个标准 Kubernetes Service ConnectorToken 认证实例返回给客户端源码位置。ACR 容器仓库docker-registry该资源类型允许 Stack Components 将一个或多个 ACR 仓库作为标准 Docker 仓库资源访问。被使用时Stack Components 会获得一个预认证的 python-docker 客户端实例。配置的凭据必须至少拥有与目标 ACR 仓库相关的以下 Azure IAM 权限允许拉取和推送镜像例如AcrPull与AcrPush角色允许列出仓库——相比宽泛的Contributor角色更建议使用Reader之类的细粒度权限或创建一个仅含Microsoft.ContainerRegistry/registries/read权限的自定义角色。资源名若设置必须采用以下两种格式之一标识 ACR 仓库ACR 仓库 URI规范资源名[https://]{registry-name}.azurecr.ioACR 仓库名{registry-name}若连接器中配置了资源组则只可访问该资源组内的 ACR 仓库。认证机制上有一个值得注意的细节当使用非服务主体的认证方法时会使用 Entra IDAzure AD认证这要求被配置的身份具有AcrPush角色若 Entra ID 认证失败则回退到管理员账户admin account认证此时需要在该仓库上启用管理员账户。源码中对应实现为_get_connector_client与内部类_ACRTokenExchangeClient服务主体认证直接以 client ID 作为用户名、client secret 作为密码其他认证则先通过 OAuth 2.0 token exchange 换取 ACR 访问令牌失败后再回退到registries.list_credentials获取管理员凭据。认证方法三种方式的选择隐式认证implicit隐式认证通过环境变量、本地配置文件、工作负载身份workload identity或托管身份managed identity向 Azure 服务进行认证。警告该方式可能存在安全风险因为它会让用户获得与 ZenML Server 自身配置相同的云资源访问权限。因此所有隐式认证方法默认处于禁用状态需要通过设置环境变量ZENML_ENABLE_IMPLICIT_AUTH_METHODS或在 ZenML 部署的 Helm Chart 中设置enableImplicitAuthMethods配置项为true来显式启用。该认证方法无需显式配置任何凭据会自动从以下来源发现并使用凭据环境变量Azure SDK 标准的环境变量体系工作负载身份workload identity——当应用部署在启用了托管身份的 AKS 上时此选项仅可用于在 AKS 集群上运行 ZenML Server 的场景托管身份managed identity——当应用部署在启用了托管身份的 Azure 主机上时此选项仅可用于在 Azure 主机上运行 ZenML 客户端或 Server 的场景Azure CLI——当用户已通过az login登录时。这是最快、最简单的 Azure 认证方式但结果取决于 ZenML 的部署形态与使用环境不具备完全可复现性使用默认本地 ZenML 部署或本地 ZenML Server 时凭据与 Azure CLI 所用凭据一致或从本地环境变量中提取连接远端 ZenML Server 时此方法仅当 Server 部署在 Azure 中才有效且会使用 Server 所在 Azure 资源如 AKS 集群附加的工作负载身份可能需要调整托管身份的权限以允许列出并访问连接器所配置访问的 Azure 资源。需要留意发现的凭据继承本地 Azure CLI 配置、环境变量或远端 Azure 托管身份的全部权限集合。鉴于权限范围可能过大该方法在生产环境可能并不合适易造成意外的权限提升privilege escalation。生产环境更推荐使用服务主体认证方法以限制签发给连接器客户端的凭据的有效期和/或权限。从源码看隐式认证通过 Azure SDK 的DefaultAzureCredential实现azure_service_connector.py且在认证前会先调用_check_implicit_auth_method_allowed()检查前述开关。示例配置前提本地 Azure CLI 已通过az login配置了用户账户凭据zenml service-connector register azure-implicit --type azure --auth-method implicit --auto-configure注册输出节选⠙ Registering service connector azure-implicit... Successfully registered service connector azure-implicit with access to the following resources: ┏━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ RESOURCE TYPE │ RESOURCE NAMES ┃ ┠───────────────────────┼───────────────────────────────────────────────┨ ┃ azure-generic │ ZenML Subscription ┃ ┠───────────────────────┼───────────────────────────────────────────────┨ ┃ blob-container │ az://demo-zenmlartifactstore ┃ ┠───────────────────────┼───────────────────────────────────────────────┨ ┃ kubernetes-cluster │ demo-zenml-demos/demo-zenml-terraform-cluster ┃ ┠───────────────────────┼───────────────────────────────────────────────┨ ┃ docker-registry │ demozenmlcontainerregistry.azurecr.io ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛此时连接器不存储任何凭据zenml service-connector describe azure-implicit输出的SECRET ID为空、SESSION DURATION为N/A即印证了这一点。Azure 服务主体service-principal服务主体凭据由Azure 客户端 IDclient ID与客户端密钥client secret组成用于向 Azure 服务认证客户端。使用该认证方法前需要先创建一个 Azure 服务主体并生成客户端密钥。连接器所需的配置字段与源码中的AzureServicePrincipalConfigazure_service_connector.py对应包括tenant_id、client_id、client_secret此外还可选subscription_id、resource_group、storage_account等字段见AzureBaseConfig源码位置。示例配置前提服务主体已配置客户端密钥并拥有访问一个 Blob 容器、一个 AKS 集群和一个 ACR 仓库的权限zenml service-connector register azure-service-principal --type azure --auth-method service-principal --tenant_ida79f3633-8f45-4a74-a42e-68871c17b7fb --client_id8926254a-8c3f-430a-a2fd-bdab234d491e --client_secretAzureSuperSecret注册成功后zenml service-connector describe azure-service-principal会显示连接器确实配置了服务主体凭据SECRET ID非空Configuration中展示tenant_id、client_id而client_secret被脱敏为[HIDDEN]。在源码中服务主体认证通过ClientSecretCredential(tenant_id, client_id, client_secret)实现azure_service_connector.py且客户端密钥使用PlainSerializedSecretStr类型存储以保证敏感信息脱敏。该认证方法是文档反复推荐的生产级选择它可以限定签发给客户端的凭据权限与有效期也是唯一支持将本机 Azure CLI 配置为连接器凭据的认证方法详见下文“本地客户端配置”。Azure 访问令牌access-token该方式使用用户显式配置或从本地环境自动配置的临时 Azure 访问令牌属于短时凭据。其最大局限在于随着 API 令牌过期用户必须定期生成新令牌并更新连接器配置。反过来它非常适合连接器仅在短期内使用的场景例如临时向团队中的其他人共享访问权限。这也是自动配置auto-configuration在本地 Azure CLI 已配置凭据时所使用的认证方法连接器会从 Azure CLI 凭据生成一个访问令牌并存入连接器配置。源码中对应的常量与逻辑为令牌默认过期时间为 3600 秒1 小时并预留 15 分钟的过期缓冲azure_service_connector.py自动配置时从DefaultAzureCredential获取https://management.azure.com/.default作用域的令牌并写入AzureAccessTokenConfig源码位置。令牌通过自定义的ZenMLAzureTokenCredential提供给 Azure 客户端源码位置。警告Azure 访问令牌的作用域限定于特定 Azure 资源而自动配置生成的访问令牌作用域为 Azure 管理 APIManagement API因此此方法不适用于 Azure Blob 存储资源。Blob 存储资源应改用服务主体认证方法。示例自动配置前提Azure CLI 已通过az login配置有效凭据zenml service-connector register azure-session-token --type azure --auto-configure注意注册输出中会明确出现一条授权失败提示这正是文档所强调的限制⠙ Registering service connector azure-session-token... connector authorization failure: the access-token authentication method is not supported for blob storage resources Successfully registered service connector azure-session-token with access to the following resources: ┏━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ RESOURCE TYPE │ RESOURCE NAMES ┃ ┠───────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────┨ ┃ azure-generic │ ZenML Subscription ┃ ┠───────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────┨ ┃ blob-container │ error: connector authorization failure: the access-token authentication method is ┃ ┃ │ not supported for blob storage resources ┃ ┠───────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────┨ ┃ kubernetes-cluster │ demo-zenml-demos/demo-zenml-terraform-cluster ┃ ┠───────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────┨ ┃ docker-registry │ demozenmlcontainerregistry.azurecr.io ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛zenml service-connector describe azure-session-token会展示其临时属性SESSION DURATION为N/AEXPIRES IN约为42m25sConfiguration中token字段为[HIDDEN]。随后zenml service-connector list --name azure-session-token输出中的EXPIRES IN会持续倒计时如40m58s直观体现了令牌的临时性——连接器约 1 小时后过期并不可用。自动配置及其两大限制Azure Service Connector 支持自动发现并从本地 Azure CLI 获取凭据与配置。警告Azure Service Connector 的自动配置存在两大限制只能提取临时 Azure 访问令牌因此无法用于长期认证场景不支持对 Azure Blob 存储服务的认证此时应改用服务主体认证方法。自动配置的完整示例见上文“Azure 访问令牌”一节。在源码层面自动配置由_auto_configure类方法实现azure_service_connector.py显式指定implicit认证方法时直接构造AzureBaseConfig否则默认生成 access-token 配置且对blob-container资源类型直接抛出AuthorizationException。本地客户端配置az、kubectl 与 docker本地 Azure CLI、KuberneteskubectlCLI 与 Docker CLI 都可以使用兼容的 Azure Service Connector 提取或生成的凭据进行配置。提示只有使用服务主体认证方法配置的连接器才能将凭据下发到本地 Azure CLI。以下演示一个基于azure-service-principal的完整本地配置流程。首先列出连接器及其可用资源zenml service-connector list --name azure-service-principal使用verify命令列出通过该连接器可访问的所有 Kubernetes 集群zenml service-connector verify azure-service-principal --resource-type kubernetes-cluster输出⠙ Verifying service connector azure-service-principal... Service connector azure-service-principal is correctly configured with valid credentials and has access to the following resources: ┏━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ RESOURCE TYPE │ RESOURCE NAMES ┃ ┠───────────────────────┼───────────────────────────────────────────────┨ ┃ kubernetes-cluster │ demo-zenml-demos/demo-zenml-terraform-cluster ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛使用login命令将本地 Kubernetes CLI 配置为访问该 AKS 集群zenml service-connector login azure-service-principal --resource-type kubernetes-cluster --resource-id demo-zenml-demos/demo-zenml-terraform-cluster输出⠙ Attempting to configure local client using service connector azure-service-principal... Updated local kubeconfig with the cluster details. The current kubectl context was set to demo-zenml-terraform-cluster. The azure-service-principal Kubernetes Service Connector was used to successfully configure the local Kubernetes cluster client/SDK.此后本地 Kubernetes CLI 即可直接与该集群交互kubectl cluster-info输出Kubernetes control plane is running at https://demo-43c5776f7.hcp.westeurope.azmk8s.io:443 CoreDNS is running at https://demo-43c5776f7.hcp.westeurope.azmk8s.io:443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy Metrics-server is running at https://demo-43c5776f7.hcp.westeurope.azmk8s.io:443/api/v1/namespaces/kube-system/services/https:metrics-server:/proxyACR 容器仓库的流程与之类似。先验证zenml service-connector verify azure-service-principal --resource-type docker-registry⠦ Verifying service connector azure-service-principal... Service connector azure-service-principal is correctly configured with valid credentials and has access to the following resources: ┏━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ RESOURCE TYPE │ RESOURCE NAMES ┃ ┠────────────────────┼───────────────────────────────────────┨ ┃ docker-registry │ demozenmlcontainerregistry.azurecr.io ┃ ┗━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛再登录zenml service-connector login azure-service-principal --resource-type docker-registry --resource-id demozenmlcontainerregistry.azurecr.io⠹ Attempting to configure local client using service connector azure-service-principal... WARNING! Your password will be stored unencrypted in /home/stefan/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store The azure-service-principal Docker Service Connector was used to successfully configure the local Docker/OCI container registry client/SDK.之后即可直接推送镜像docker push demozenmlcontainerregistry.azurecr.io/zenml:example_pipelineThe push refers to repository [demozenmlcontainerregistry.azurecr.io/zenml] d4aef4f5ed86: Pushed 2d69a4ce1784: Pushed ... connectors: digest: sha256:a4cfb18a5cef5b2201759a42dd9fe8eb2f833b788e9d8a6ebde194765b42fe46 size: 3256还可以用login命令将本地 Azure CLI 更新为连接器的服务主体凭据zenml service-connector login azure-service-principal --resource-type azure-genericUpdated the local Azure CLI configuration with the connectors service principal credentials. The azure-service-principal Azure Service Connector was used to successfully configure the local Generic Azure resource client/SDK.从源码看_configure_local_client方法azure_service_connector.py仅在认证方法为service-principal时执行az login --service-principal -u client_id -p client_secret --tenant tenant_id子进程调用来更新本地 Azure CLI而 Kubernetes 与 Docker 客户端的配置则经由_get_connector_client生成的客户端侧连接器实例完成kubectl 场景下写入本地 kubeconfigDocker 场景下执行 docker login。这也解释了为什么本地 Azure CLI 配置仅支持服务主体认证方法。连接 Stack Components 使用Azure Service Connector 可以与以下 ZenML Stack Components 协同工作Azure Artifact Store通过连接器连接到远程 Azure Blob 存储容器依赖 Kubernetes 集群的任何 Orchestrator 或 Model Deployer flavor可在不于目标环境或 Stack Component 中显式配置与维护 Azure 或 Kuberneteskubectl配置上下文与凭据的情况下管理 AKS 上的 Kubernetes 容器工作负载Container Registry Stack Components通过连接器连接到 ACR 容器仓库从而在不于目标环境或 Stack Component 中配置显式 Azure 凭据的情况下构建并发布容器镜像到私有 ACR 仓库。端到端示例AKS Orchestrator Azure Blob Artifact Store ACR一个多类型连接器搞定下面演示一个完整的端到端工作流使用一个多类型multi-typeAzure Service Connector为多个 Stack Components 提供对多个资源的访问。最终注册的完整 ZenML Stack 由以下组件构成全部通过同一个连接器连接一个连接到 AKS Kubernetes 集群的 Kubernetes Orchestrator一个连接到 Azure Blob 存储容器的 Azure Blob Storage Artifact Store一个连接到 ACR 容器仓库的 Azure Container Registry一个本地 Image Builder。最后在生成的 Stack 上运行一个简单管道。注意该示例需要从 Azure 可达的远程 ZenML Server。Step 1创建一个带客户端密钥的 Azure 服务主体授予其访问 Blob 容器、AKS 集群与 ACR 仓库的权限并安装 Azure 集成zenml integration install -y azureStep 2确认 Azure Service Connector 类型可用zenml service-connector list-types --type azure输出即本文开头的能力矩阵表格。Step 3使用服务主体凭据注册多类型 Azure Service Connectorzenml service-connector register azure-service-principal --type azure --auth-method service-principal --tenant_ida79ff3633-8f45-4a74-a42e-68871c17b7fb --client_id8926254a-8c3f-430a-a2fd-bdab234fd491e --client_secretAzureSuperSecret注册输出会列出该连接器可访问的全部资源⠸ Registering service connector azure-service-principal... Successfully registered service connector azure-service-principal with access to the following resources: ┏━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ RESOURCE TYPE │ RESOURCE NAMES ┃ ┠───────────────────────┼───────────────────────────────────────────────┨ ┃ azure-generic │ ZenML Subscription ┃ ┠───────────────────────┼───────────────────────────────────────────────┨ ┃ blob-container │ az://demo-zenmlartifactstore ┃ ┠───────────────────────┼───────────────────────────────────────────────┨ ┃ kubernetes-cluster │ demo-zenml-demos/demo-zenml-terraform-cluster ┃ ┠───────────────────────┼───────────────────────────────────────────────┨ ┃ docker-registry │ demozenmlcontainerregistry.azurecr.io ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛Step 4注册 Azure Blob 存储 Artifact Store 并连接到 Blob 容器zenml artifact-store register azure-demo --flavor azure --pathaz://demo-zenmlartifactstore zenml artifact-store connect azure-demo --connector azure-service-principal连接输出节选Successfully connected artifact store azure-demo to the following resources: ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ CONNECTOR ID │ CONNECTOR NAME │ CONNECTOR TYPE │ RESOURCE TYPE │ RESOURCE NAMES ┃ ┠──────────────────────────────────────┼─────────────────────────┼────────────────┼───────────────────┼──────────────────────────────┨ ┃ f2316191-d20b-4348-a68b-f5e347862196 │ azure-service-principal │ azure │ blob-container │ az://demo-zenmlartifactstore ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛Step 5注册 Kubernetes Orchestrator 并连接到 AKS 集群zenml orchestrator register aks-demo-cluster --flavor kubernetes --synchronoustrue --kubernetes_namespacezenml-workloads zenml orchestrator connect aks-demo-cluster --connector azure-service-principal连接输出节选Successfully connected orchestrator aks-demo-cluster to the following resources: ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ CONNECTOR ID │ CONNECTOR NAME │ CONNECTOR TYPE │ RESOURCE TYPE │ RESOURCE NAMES ┃ ┠──────────────────────────────────────┼─────────────────────────┼────────────────┼───────────────────────┼───────────────────────────────────────────────┨ ┃ f2316191-d20b-4348-a68b-f5e347862196 │ azure-service-principal │ azure │ kubernetes-cluster │ demo-zenml-demos/demo-zenml-terraform-cluster ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛Step 6注册 Azure Container Registry 并连接到 ACR 仓库zenml container-registry register acr-demo-registry --flavor azure --uridemozenmlcontainerregistry.azurecr.io zenml container-registry connect acr-demo-registry --connector azure-service-principal连接输出节选Successfully connected container registry acr-demo-registry to the following resources: ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ CONNECTOR ID │ CONNECTOR NAME │ CONNECTOR TYPE │ RESOURCE TYPE │ RESOURCE NAMES ┃ ┠──────────────────────────────────────┼─────────────────────────┼────────────────┼────────────────────┼───────────────────────────────────────┨ ┃ f2316191-d20b-4348-a68b-f5e347862196 │ azure-service-principal │ azure │ docker-registry │ demozenmlcontainerregistry.azurecr.io ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛注意三个组件连接到的CONNECTOR ID完全相同——这正是多类型连接器的核心价值一份凭据、一个连接器服务多个 Stack Components。Step 7将各组件组合成 Stack 并设为 active顺带注册一个本地 Image Builderzenml image-builder register local --flavor local zenml stack register gcp-demo -a azure-demo -o aks-demo-cluster -c acr-demo-registry -i local --set输出Stack gcp-demo successfully registered! Active repository stack set to:gcp-demoStep 8编写并运行一个最简单的管道验证整条链路from zenml import pipeline, step step def step_1() - str: Returns the world string. return world step(enable_cacheFalse) def step_2(input_one: str, input_two: str) - None: Combines the two strings at its input and prints them. combined_str f{input_one} {input_two} print(combined_str) pipeline def my_pipeline(): output_step_one step_1() step_2(input_onehello, input_twooutput_step_one) if __name__ __main__: my_pipeline()将上述代码保存为run.py并执行$ python run.py Building Docker image(s) for pipeline simple_pipeline. Building Docker image demozenmlcontainerregistry.azurecr.io/zenml:simple_pipeline-orchestrator. - Including integration requirements: adlfs2021.10.0, azure-identity1.4.0, azure-mgmt-containerregistry10.0.0, azure-mgmt-containerservice20.0.0, azure-mgmt-resource21.0.0,25.0.0, azure-mgmt-storage20.0.0, azure-storage-blob12.17.0,13.0.0, kubernetes18.20.0, requests2.27.11,3.0.0, azure-ai-ml1.23.1,2.0.0, marshmallow4.0.0 ... Pushing Docker image demozenmlcontainerregistry.azurecr.io/zenml:simple_pipeline-orchestrator. Finished pushing Docker image. Finished building Docker image(s). Running pipeline simple_pipeline on stack gcp-demo (caching disabled) Waiting for Kubernetes orchestrator pod... Kubernetes orchestrator pod started. Waiting for pod of step simple_step_one to start... Step simple_step_one has started. INFO:azure.identity._internal.get_token_mixin:ClientSecretCredential.get_token succeeded ... Step simple_step_one has finished in 0.396s. ... Hello World! Step simple_step_two has finished in 3.203s. Orchestration pod completed. Dashboard URL: https://zenml.stefan.20.23.46.143.nip.io/default/pipelines/98c41e2a-1ab0-4ec9-8375-6ea1ab473686/runs日志中的ClientSecretCredential.get_token succeeded证实了管道运行时AKS 上的 Kubernetes Pod 正是通过连接器下发的服务主体凭据完成了对 Azure Blob 存储与 ACR 的认证——整个过程中无需在目标环境或 Stack Component 中手工配置任何 Azure 凭据。安全最佳实践与注意事项优先使用服务主体认证隐式认证继承的权限范围不可控且在服务端默认关闭访问令牌有效期短、维护成本高且不支持 Blob 存储。服务主体是文档推荐的生产级选择。最小权限原则为连接器配置的 Azure IAM 权限应尽量收窄如Storage Blob Data Contributor、AcrPull/AcrPush、Azure Kubernetes Service Cluster Admin Role并通过连接器的resource_group、storage_account等配置项对应源码中的AzureBaseConfig字段见 azure_service_connector.py将访问范围限制在必要的资源内。使用 verify 验证连接器zenml service-connector verify是排查凭据与权限问题的首选工具可按--resource-type与--resource-id精确验证某一类或某一个资源的可达性其底层逻辑对应源码中的_verify方法。留意临时凭据的过期访问令牌类凭据约 1 小时过期本地 CLI 通过连接器获取的临时凭据同样会过期需要时需重新执行zenml service-connector login获取新凭据。服务端开关若要在 ZenML Server 部署中启用隐式认证必须显式设置环境变量ZENML_ENABLE_IMPLICIT_AUTH_METHODS或 Helm Chart 的enableImplicitAuthMethods为true。关于各类认证方法在开发/生产环境中的取舍、短时凭据与权限收窄的更深入讨论可继续阅读Service Connector 安全最佳实践对连接器的注册、作用域多类型/多实例/单实例、验证与本地客户端配置等通用操作可参考Service Connector 完整指南若希望同时对比 AWS 与 GCP 的对应实现仓库中还有 AWS Service Connector 与 GCP Service Connector 的同类文档可供查阅。【免费下载链接】zenmlZenML : One AI Platform from Pipelines to Agents. https://zenml.io.项目地址: https://gitcode.com/GitHub_Trending/ze/zenml创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考