Backstage Kubernetes 插件如何配置认证以访问集群【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstage在 Backstage 中接入了 Kubernetes 插件后常见的问题是前端实体页面看不到任何集群资源或者只看到集群名却加载不出对象。根本原因几乎都是插件的认证没有配好。本文的任务是完成 Kubernetes 插件的安装后在app-config.yaml中为集群选择并配置认证方式authProvider配合 RBAC 权限和实体关联标注最终让 Software Catalog 实体页面上的 Kubernetes 标签正常列出该实体对应的 pods、services、deployments 等资源。适用环境是已经按 Getting Started 指南搭建好的 Backstage 实例。先安装 Kubernetes 前端与后端插件认证配置依附于插件本身两步安装缺一不可。在 Backstage 根目录执行yarn --cwd packages/app add backstage/plugin-kubernetes前端插件安装后通过默认 feature discovery 自动生效会为关联了 Kubernetes 资源的实体页面添加 Kubernetes 标签。然后安装后端插件yarn --cwd packages/backend add backstage/plugin-kubernetes-backend并在packages/backend/src/index.ts中注册const backend createBackend(); // Other plugins... backend.add(import(backstage/plugin-kubernetes-backend)); backend.start();理解两类认证提供者选择你的 authProviderBackstage 的 Kubernetes 认证由KubernetesAuthProviders完成注意它和 Backstage 应用自身的登录认证不是同一套东西。文档把它们分为两类这决定了认证配置的写法Server Side Providers认证的是你的应用。任何登录了 Backstage 的用户包括 guest都获得同一套 Kubernetes 访问权限。可用值aws、azure、googleServiceAccount、localKubectlProxy、serviceAccount。Client Side Providers认证的是用户。每个用户会被要求提供凭据只能访问自己被授权的资源。可用值aks、google、oidc。如果集群已配置但用户无权限该集群会列出但看不到资源错误表现为401或类似错误。authProvider字段的完整取值与含义值说明aks使用用户的 AKS access token来自 Microsoft auth provider访问 AKS 集群aws使用 AWS 凭据访问 EKS 集群资源azure使用 Azure Identity 访问集群资源google使用用户的 Google access token 访问 GKE 集群googleServiceAccount使用 Google Cloud 服务账号凭据访问集群资源oidc使用 OIDC token 认证必须同时设置oidcTokenProvider且集群须支持 OIDC文档指出 AKS 集群当时不支持 OIDCserviceAccount使用 Kubernetes 服务账号访问 API须同时设置serviceAccountToken否则 Backstage 必须运行在集群内以下按文档给出三条主配置路径本地/自建集群的serviceAccount、AWS 的aws、以及oidc。路径一serviceAccount本地集群与自建集群在app-config.yaml中通过clusterLocatorMethods的config方法声明集群。完整示例本地 minikube来自 configuration 文档kubernetes: serviceLocatorMethod: type: multiTenant clusterLocatorMethods: - type: config clusters: - url: http://127.0.0.1:9999 name: minikube authProvider: serviceAccount skipTLSVerify: false skipMetricsLookup: true serviceAccountToken: ${K8S_MINIKUBE_TOKEN} caData: ${K8S_CONFIG_CA_DATA} caFile: # local path to CA file关键字段说明均以上下文文档为准urlKubernetes control plane 的 base URL可通过kubectl cluster-info的 Kubernetes master 结果获得。name集群在 Software Catalog Kubernetes 页面中显示的名称在clusters数组内必须唯一。serviceAccountTokenserviceAccount认证提供者使用的 token这里以环境变量注入。文档同时提醒除非你有有效的凭据轮换机制或只有一个同时运行 Backstage 与全部服务的集群否则该方式不太适合生产环境。caDatabase64 编码的 PEM 格式 CA bundle可从kubeconfig通常是~/.kube/config的clusters[*].cluster.certificate-authority-data字段获取。GKE 可用gcloud container clusters describe YOUR_CLUSTER_NAME --zoneYOUR_COMPUTE_ZONE --formatvalue(masterAuth.clusterCaCertificate)获取。skipTLSVerify是否跳过 API server 的 TLS 证书校验默认false。skipMetricsLookup是否跳过 pod 的 CPU/内存指标查询默认false。如果authProvider: serviceAccount的集群省略了serviceAccountToken字段Backstage 会忽略配置的 URL 和证书数据改用 in-cluster client 方式访问。获取 long-lived service account token假设你已在NAMESPACE命名空间创建了名为SERVICE_ACCOUNT_NAME的服务账号并授予足够权限。按 Kubernetes 版本获取 tokenNAMESPACE、SERVICE_ACCOUNT_NAME、SECRET_NAME替换为你的实际值Kubernetes 1.24 之前可以读取服务账号自动生成的 tokenkubectl -n NAMESPACE get secret $(kubectl -n NAMESPACE get sa SERVICE_ACCOUNT_NAME -ojson \ | jq -r .secrets[0].name) -ojson \ | jq -r .data[token] \ | base64 --decodeKubernetes 1.24 及以后先创建绑定服务账号的 Secret等待 token controller 填充后取回kubectl apply -f - EOF apiVersion: v1 kind: Secret metadata: name: SECRET_NAME namespace: NAMESPACE annotations: kubernetes.io/service-account.name: SERVICE_ACCOUNT_NAME type: kubernetes.io/service-account-token EOFkubectl -n NAMESPACE get secret SECRET_NAME -o go-template{{.data.token | base64decode}}集群侧 RBAC 权限插件所需的集群侧权限是 read-only cluster wide。以下 manifest 来自文档能确保插件正常工作--- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: backstage-read-only rules: - apiGroups: - * resources: - pods - pods/log - configmaps - services - deployments - replicasets - horizontalpodautoscalers - ingresses - statefulsets - limitranges - resourcequotas - daemonsets verbs: - get - list - watch - apiGroups: - batch resources: - jobs - cronjobs verbs: - get - list - watch - apiGroups: - metrics.k8s.io resources: - pods verbs: - get - list将NAMESPACE等替换为实际值后把该 ClusterRole 绑定到你的服务账号再应用即可。路径二awsEKS 集群使用aws认证提供者时除 Kubernetes 配置外还必须配置 AWS 认证。它通过 AWS IAM 向目标账号认证支持三种凭据来源静态 Access keys、通过 assume role 生成的短期 Access keys或用于 OIDC federation如 GCP Workload Identity Federation的 web identity token 文件。前两种需要安装并配置 AWS CLI。静态密钥的 AWS 配置块aws: mainAccount: accounts: - accountId: account-number accessKeyId: ${AWS_ACCESS_KEY_ID} secretAccessKey: ${AWS_SECRET_ACCESS_KEY} region: region accountDefaults:Assume role 环境则改为aws: mainAccount: roleName: name-of-the-role-to-assume region: region accounts: accountDefaults:非 AWS 环境例如 GCP Workload Identity Federation可使用 web identity token 文件aws: accountDefaults: roleName: name-of-the-role-to-assume webIdentityTokenFile: path-to-token-file对应的 Kubernetes 配置authMetadata中的 key 即文档中的authMetadata注解项${...}为环境变量尖括号项替换为你的实际值kubernetes: serviceLocatorMethod: type: multiTenant clusterLocatorMethods: - type: config clusters: - url: https://unique-identifier.region.eks.amazonaws.com name: ${CLUSTER_NAME_TO_DISPLAY} authProvider: aws caData: ${EKS_CA_DATA} authMetadata: kubernetes.io/aws-assume-role: ${ROLE_ARN_TO_ASSUME} kubernetes.io/aws-external-id: ${ID_FROM_AWS_ADMIN} kubernetes.io/x-k8s-aws-id: ${CLUSTER_NAME_IN_AWS_CONSOLE}集群 URL 和 CA 直接从 AWS 控制台获取进入EKSYour clusterOverviewDetails分别在 API server endpoint 和 Certificate authority 下找到。kubernetes.io/aws-assume-role设置为要 assume 的角色 ARNkubernetes.io/aws-external-id对应 STSAssumeRoleAPI 的ExternalId参数。当设置了kubernetes.io/aws-assume-role时会用角色 ARN 中的 account ID 去匹配accounts或accountDefaults配置匹配到的凭据作为 assume role 的源凭据。注意上述两个 sectionAWS 配置块与 Kubernetes 配置块都需要存在aws认证提供者才生效。路径三oidc用户级认证可选分支oidc使用 OIDC token 向 Kubernetes API 认证oidcTokenProvider指定从哪个 Backstage auth provider 取 id token该 provider 必须已在auth下正确配置kubernetes: clusterLocatorMethods: - type: config clusters: - name: test-cluster url: http://localhost:8080 authProvider: oidc oidcTokenProvider: okta # This value needs to match a config under auth.providers auth: providers: okta: development: clientId: ${AUTH_OKTA_CLIENT_ID} clientSecret: ${AUTH_OKTA_CLIENT_SECRET} audience: ${AUTH_OKTA_AUDIENCE}前端开箱即支持的值gitlab对应应用需被授予openidscope、google、microsoft、okta、onelogin。文档特别提醒oidcTokenProvider只是 token 的 issuer例如可以用microsoft作为 EKS 集群的 issuer。AzureAKS配置说明azure提供者在服务端通过 Azure CLI 认证前提是集群已启用 Microsoft Entra authentication。步骤在 Backstage 运行的环境安装 Azure CLI在服务器终端执行az login登录在 Azure Console 进入 AKS 集群资源页按Connect标签的步骤设置订阅并获取kubectl集成凭据然后配置kubernetes: clusterLocatorMethods: - type: config clusters: - name: My AKS cluster url: ${AZURE_CLUSTER_API_SERVER_ADDRESS} authProvider: azure skipTLSVerify: trueAPI server 地址从 Azure 控制台的集群资源页OverviewPropertiesNetworking复制。将实体与集群资源关联认证配好后还要让 Backstage 知道哪些集群资源属于哪个实体。在实体的catalog-info.yaml中添加注解annotations: backstage.io/kubernetes-id: dice-roller可选地用backstage.io/kubernetes-namespace限定命名空间查找。对应的 Kubernetes 资源service、deployment、ingress 等需要带相同 key 的 labelmetadata: labels: backstage.io/kubernetes-id: BACKSTAGE_ENTITY_NAMEk8s-app-name与service-entity-name可以不同但文档建议保持一致。也可用backstage.io/kubernetes-label-selector写自定义 label selector 查询替代精确 id 匹配label selector 优先级高于 annotation/service id。验证配置是否生效用文档给出的 curl 命令检查集群是否已连通{{backstage-backend-url}}:{{backstage-backend-port}}替换为你的 Backstage 后端实际地址:service-entity-name与服务名替换为实际实体名curl --location --request POST http://backstage-backend-host:port/api/kubernetes/services/service-entity-name \ --header Content-Type: application/json \ --data-raw { entity: { metadata: { name: service-entity-name } } }成功的判断方式是响应items中包含对应cluster和resourcesservices、pods 等且errors为空。文档示例响应结构{ items: [ { cluster: { name: cluster-name }, resources: [ { type: services, resources: [ { metadata: { labels: { backstage.io/kubernetes-id: service-entity-name }, name: k8s-app-name, namespace: namespace } } ] } ], errors: [] } ] }以上尖括号均为占位符实际输出中的名称以你环境为准。最后到 Backstage 实体页面确认 Kubernetes 标签中能看到这些资源。排查与限制Kubernetes 标签什么都不显示先确认catalog-info.yaml注解与集群资源 label 是否匹配这是文档列出的最常见原因再用上面的 curl 命令区分是集群没连通还是实体没关联上。用户看不到资源但集群已列出这是 client side 提供者的正常行为——用户未被授权访问该集群时错误显示为401或类似需要为该用户配置集群侧授权。localKubectlProxy假定本地有kubectl proxy默认端口 8001在运行文档明确它只用于本地开发不应在生产环境使用。catalog cluster locator 不支持serviceAccount把 token 放在 catalog 实体注解里是不安全的因此 catalog 定位器会忽略使用serviceAccount策略的实体且serviceAccountToken等敏感 key 不能从 catalog 实体提供。多个定位器共存时可将clusterLocatorContinueOnError设为true这样单个定位器如某个 GKE 项目的权限错误失败时其余成功定位器返回的集群仍会返回默认false时任一失败会导致整个集群列表请求失败。完成认证配置、RBAC 授权与实体关联后实体页面的 Kubernetes 标签即可展示真实资源。如需进一步限制谁可以调用/clusters、/services/:serviceId、/resources、/proxy等端点可结合权限框架配置kubernetes.clusters.read、kubernetes.resources.read与kubernetes.proxy权限见 Permissions 文档。完整认证机制与自定义AuthenticationStrategy的说明见 Kubernetes Authentication 与 Authentication Strategies各配置字段的细节见 Configuring Kubernetes integration。【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Backstage Kubernetes 插件如何配置认证以访问集群？
Backstage Kubernetes 插件如何配置认证以访问集群【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstage在 Backstage 中接入了 Kubernetes 插件后常见的问题是前端实体页面看不到任何集群资源或者只看到集群名却加载不出对象。根本原因几乎都是插件的认证没有配好。本文的任务是完成 Kubernetes 插件的安装后在app-config.yaml中为集群选择并配置认证方式authProvider配合 RBAC 权限和实体关联标注最终让 Software Catalog 实体页面上的 Kubernetes 标签正常列出该实体对应的 pods、services、deployments 等资源。适用环境是已经按 Getting Started 指南搭建好的 Backstage 实例。先安装 Kubernetes 前端与后端插件认证配置依附于插件本身两步安装缺一不可。在 Backstage 根目录执行yarn --cwd packages/app add backstage/plugin-kubernetes前端插件安装后通过默认 feature discovery 自动生效会为关联了 Kubernetes 资源的实体页面添加 Kubernetes 标签。然后安装后端插件yarn --cwd packages/backend add backstage/plugin-kubernetes-backend并在packages/backend/src/index.ts中注册const backend createBackend(); // Other plugins... backend.add(import(backstage/plugin-kubernetes-backend)); backend.start();理解两类认证提供者选择你的 authProviderBackstage 的 Kubernetes 认证由KubernetesAuthProviders完成注意它和 Backstage 应用自身的登录认证不是同一套东西。文档把它们分为两类这决定了认证配置的写法Server Side Providers认证的是你的应用。任何登录了 Backstage 的用户包括 guest都获得同一套 Kubernetes 访问权限。可用值aws、azure、googleServiceAccount、localKubectlProxy、serviceAccount。Client Side Providers认证的是用户。每个用户会被要求提供凭据只能访问自己被授权的资源。可用值aks、google、oidc。如果集群已配置但用户无权限该集群会列出但看不到资源错误表现为401或类似错误。authProvider字段的完整取值与含义值说明aks使用用户的 AKS access token来自 Microsoft auth provider访问 AKS 集群aws使用 AWS 凭据访问 EKS 集群资源azure使用 Azure Identity 访问集群资源google使用用户的 Google access token 访问 GKE 集群googleServiceAccount使用 Google Cloud 服务账号凭据访问集群资源oidc使用 OIDC token 认证必须同时设置oidcTokenProvider且集群须支持 OIDC文档指出 AKS 集群当时不支持 OIDCserviceAccount使用 Kubernetes 服务账号访问 API须同时设置serviceAccountToken否则 Backstage 必须运行在集群内以下按文档给出三条主配置路径本地/自建集群的serviceAccount、AWS 的aws、以及oidc。路径一serviceAccount本地集群与自建集群在app-config.yaml中通过clusterLocatorMethods的config方法声明集群。完整示例本地 minikube来自 configuration 文档kubernetes: serviceLocatorMethod: type: multiTenant clusterLocatorMethods: - type: config clusters: - url: http://127.0.0.1:9999 name: minikube authProvider: serviceAccount skipTLSVerify: false skipMetricsLookup: true serviceAccountToken: ${K8S_MINIKUBE_TOKEN} caData: ${K8S_CONFIG_CA_DATA} caFile: # local path to CA file关键字段说明均以上下文文档为准urlKubernetes control plane 的 base URL可通过kubectl cluster-info的 Kubernetes master 结果获得。name集群在 Software Catalog Kubernetes 页面中显示的名称在clusters数组内必须唯一。serviceAccountTokenserviceAccount认证提供者使用的 token这里以环境变量注入。文档同时提醒除非你有有效的凭据轮换机制或只有一个同时运行 Backstage 与全部服务的集群否则该方式不太适合生产环境。caDatabase64 编码的 PEM 格式 CA bundle可从kubeconfig通常是~/.kube/config的clusters[*].cluster.certificate-authority-data字段获取。GKE 可用gcloud container clusters describe YOUR_CLUSTER_NAME --zoneYOUR_COMPUTE_ZONE --formatvalue(masterAuth.clusterCaCertificate)获取。skipTLSVerify是否跳过 API server 的 TLS 证书校验默认false。skipMetricsLookup是否跳过 pod 的 CPU/内存指标查询默认false。如果authProvider: serviceAccount的集群省略了serviceAccountToken字段Backstage 会忽略配置的 URL 和证书数据改用 in-cluster client 方式访问。获取 long-lived service account token假设你已在NAMESPACE命名空间创建了名为SERVICE_ACCOUNT_NAME的服务账号并授予足够权限。按 Kubernetes 版本获取 tokenNAMESPACE、SERVICE_ACCOUNT_NAME、SECRET_NAME替换为你的实际值Kubernetes 1.24 之前可以读取服务账号自动生成的 tokenkubectl -n NAMESPACE get secret $(kubectl -n NAMESPACE get sa SERVICE_ACCOUNT_NAME -ojson \ | jq -r .secrets[0].name) -ojson \ | jq -r .data[token] \ | base64 --decodeKubernetes 1.24 及以后先创建绑定服务账号的 Secret等待 token controller 填充后取回kubectl apply -f - EOF apiVersion: v1 kind: Secret metadata: name: SECRET_NAME namespace: NAMESPACE annotations: kubernetes.io/service-account.name: SERVICE_ACCOUNT_NAME type: kubernetes.io/service-account-token EOFkubectl -n NAMESPACE get secret SECRET_NAME -o go-template{{.data.token | base64decode}}集群侧 RBAC 权限插件所需的集群侧权限是 read-only cluster wide。以下 manifest 来自文档能确保插件正常工作--- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: backstage-read-only rules: - apiGroups: - * resources: - pods - pods/log - configmaps - services - deployments - replicasets - horizontalpodautoscalers - ingresses - statefulsets - limitranges - resourcequotas - daemonsets verbs: - get - list - watch - apiGroups: - batch resources: - jobs - cronjobs verbs: - get - list - watch - apiGroups: - metrics.k8s.io resources: - pods verbs: - get - list将NAMESPACE等替换为实际值后把该 ClusterRole 绑定到你的服务账号再应用即可。路径二awsEKS 集群使用aws认证提供者时除 Kubernetes 配置外还必须配置 AWS 认证。它通过 AWS IAM 向目标账号认证支持三种凭据来源静态 Access keys、通过 assume role 生成的短期 Access keys或用于 OIDC federation如 GCP Workload Identity Federation的 web identity token 文件。前两种需要安装并配置 AWS CLI。静态密钥的 AWS 配置块aws: mainAccount: accounts: - accountId: account-number accessKeyId: ${AWS_ACCESS_KEY_ID} secretAccessKey: ${AWS_SECRET_ACCESS_KEY} region: region accountDefaults:Assume role 环境则改为aws: mainAccount: roleName: name-of-the-role-to-assume region: region accounts: accountDefaults:非 AWS 环境例如 GCP Workload Identity Federation可使用 web identity token 文件aws: accountDefaults: roleName: name-of-the-role-to-assume webIdentityTokenFile: path-to-token-file对应的 Kubernetes 配置authMetadata中的 key 即文档中的authMetadata注解项${...}为环境变量尖括号项替换为你的实际值kubernetes: serviceLocatorMethod: type: multiTenant clusterLocatorMethods: - type: config clusters: - url: https://unique-identifier.region.eks.amazonaws.com name: ${CLUSTER_NAME_TO_DISPLAY} authProvider: aws caData: ${EKS_CA_DATA} authMetadata: kubernetes.io/aws-assume-role: ${ROLE_ARN_TO_ASSUME} kubernetes.io/aws-external-id: ${ID_FROM_AWS_ADMIN} kubernetes.io/x-k8s-aws-id: ${CLUSTER_NAME_IN_AWS_CONSOLE}集群 URL 和 CA 直接从 AWS 控制台获取进入EKSYour clusterOverviewDetails分别在 API server endpoint 和 Certificate authority 下找到。kubernetes.io/aws-assume-role设置为要 assume 的角色 ARNkubernetes.io/aws-external-id对应 STSAssumeRoleAPI 的ExternalId参数。当设置了kubernetes.io/aws-assume-role时会用角色 ARN 中的 account ID 去匹配accounts或accountDefaults配置匹配到的凭据作为 assume role 的源凭据。注意上述两个 sectionAWS 配置块与 Kubernetes 配置块都需要存在aws认证提供者才生效。路径三oidc用户级认证可选分支oidc使用 OIDC token 向 Kubernetes API 认证oidcTokenProvider指定从哪个 Backstage auth provider 取 id token该 provider 必须已在auth下正确配置kubernetes: clusterLocatorMethods: - type: config clusters: - name: test-cluster url: http://localhost:8080 authProvider: oidc oidcTokenProvider: okta # This value needs to match a config under auth.providers auth: providers: okta: development: clientId: ${AUTH_OKTA_CLIENT_ID} clientSecret: ${AUTH_OKTA_CLIENT_SECRET} audience: ${AUTH_OKTA_AUDIENCE}前端开箱即支持的值gitlab对应应用需被授予openidscope、google、microsoft、okta、onelogin。文档特别提醒oidcTokenProvider只是 token 的 issuer例如可以用microsoft作为 EKS 集群的 issuer。AzureAKS配置说明azure提供者在服务端通过 Azure CLI 认证前提是集群已启用 Microsoft Entra authentication。步骤在 Backstage 运行的环境安装 Azure CLI在服务器终端执行az login登录在 Azure Console 进入 AKS 集群资源页按Connect标签的步骤设置订阅并获取kubectl集成凭据然后配置kubernetes: clusterLocatorMethods: - type: config clusters: - name: My AKS cluster url: ${AZURE_CLUSTER_API_SERVER_ADDRESS} authProvider: azure skipTLSVerify: trueAPI server 地址从 Azure 控制台的集群资源页OverviewPropertiesNetworking复制。将实体与集群资源关联认证配好后还要让 Backstage 知道哪些集群资源属于哪个实体。在实体的catalog-info.yaml中添加注解annotations: backstage.io/kubernetes-id: dice-roller可选地用backstage.io/kubernetes-namespace限定命名空间查找。对应的 Kubernetes 资源service、deployment、ingress 等需要带相同 key 的 labelmetadata: labels: backstage.io/kubernetes-id: BACKSTAGE_ENTITY_NAMEk8s-app-name与service-entity-name可以不同但文档建议保持一致。也可用backstage.io/kubernetes-label-selector写自定义 label selector 查询替代精确 id 匹配label selector 优先级高于 annotation/service id。验证配置是否生效用文档给出的 curl 命令检查集群是否已连通{{backstage-backend-url}}:{{backstage-backend-port}}替换为你的 Backstage 后端实际地址:service-entity-name与服务名替换为实际实体名curl --location --request POST http://backstage-backend-host:port/api/kubernetes/services/service-entity-name \ --header Content-Type: application/json \ --data-raw { entity: { metadata: { name: service-entity-name } } }成功的判断方式是响应items中包含对应cluster和resourcesservices、pods 等且errors为空。文档示例响应结构{ items: [ { cluster: { name: cluster-name }, resources: [ { type: services, resources: [ { metadata: { labels: { backstage.io/kubernetes-id: service-entity-name }, name: k8s-app-name, namespace: namespace } } ] } ], errors: [] } ] }以上尖括号均为占位符实际输出中的名称以你环境为准。最后到 Backstage 实体页面确认 Kubernetes 标签中能看到这些资源。排查与限制Kubernetes 标签什么都不显示先确认catalog-info.yaml注解与集群资源 label 是否匹配这是文档列出的最常见原因再用上面的 curl 命令区分是集群没连通还是实体没关联上。用户看不到资源但集群已列出这是 client side 提供者的正常行为——用户未被授权访问该集群时错误显示为401或类似需要为该用户配置集群侧授权。localKubectlProxy假定本地有kubectl proxy默认端口 8001在运行文档明确它只用于本地开发不应在生产环境使用。catalog cluster locator 不支持serviceAccount把 token 放在 catalog 实体注解里是不安全的因此 catalog 定位器会忽略使用serviceAccount策略的实体且serviceAccountToken等敏感 key 不能从 catalog 实体提供。多个定位器共存时可将clusterLocatorContinueOnError设为true这样单个定位器如某个 GKE 项目的权限错误失败时其余成功定位器返回的集群仍会返回默认false时任一失败会导致整个集群列表请求失败。完成认证配置、RBAC 授权与实体关联后实体页面的 Kubernetes 标签即可展示真实资源。如需进一步限制谁可以调用/clusters、/services/:serviceId、/resources、/proxy等端点可结合权限框架配置kubernetes.clusters.read、kubernetes.resources.read与kubernetes.proxy权限见 Permissions 文档。完整认证机制与自定义AuthenticationStrategy的说明见 Kubernetes Authentication 与 Authentication Strategies各配置字段的细节见 Configuring Kubernetes integration。【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考