前端后端云原生【免费下载链接】dashboardGeneral-purpose web UI for Kubernetes clusters项目地址https://gitcode.com/gh_mirrors/da/dashboard点击查看免费下载导读本文聚焦 Kubernetes Dashboard 的访问控制体系讲解 Dashboard 在认证/授权链路中扮演的代理角色、其自身各组件的默认 RBAC 权限以及两种核心用户认证方式Authorization Header 与 Bearer Token的原理与实战用法。文章以 docs/user/access-control/README.md 与 docs/user/access-control/creating-sample-user.md 为主体骨架并深入 modules 源码与 charts/kubernetes-dashboard/templates/rbac Helm 模板帮助读者理解底层实现、掌握从零创建具备管理员权限的用户并安全登录 Dashboard 的完整流程。一、Dashboard 在 Kubernetes 访问控制中的角色Kubernetes 本身提供多种用户认证Authentication与授权Authorization机制其中授权由 API Server 统一裁决。Dashboard 在此链路中只扮演一个反向代理Proxy它把用户的认证信息原样传递给 Kubernetes API Server自身不做任何授权决策。认证验证你是谁由 API Server 的认证插件如 Token、X.509 证书、OIDC 等负责授权决定你能做什么由 API Server 的授权模块默认 RBAC负责当用户对被访问的资源没有权限时API Server 会返回禁止访问ForbiddenDashboard 会将这些错误以警告形式展示在界面上。这意味着你在 Dashboard 上看到的能力边界完全取决于登录时使用的凭证所对应的 RBAC 权限。Dashboard 自身默认的 RBAC 权限极小仅够它运行自身功能绝不会替用户开绿灯。二、Dashboard 默认 RBAC 权限通过 Helm Chart 安装 Dashboard 时会为三个容器分别创建最小化的 RBAC 角色其定义位于 charts/kubernetes-dashboard/templates/rbac 目录下。2.1 Web 容器Web 容器仅需要对设置存储所用的 ConfigMap拥有get和update权限对应模板 charts/kubernetes-dashboard/templates/rbac/web/role.yamlkind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: {{ template kubernetes-dashboard.fullname . }}-{{ .Values.web.role }} rules: # Allow Dashboard Web to get and update kubernetes-dashboard-settings config map. - apiGroups: [ ] resources: [ configmaps ] resourceNames: [ {{ template kubernetes-dashboard.web.configMap.settings.name . }} ] verbs: [ get, update ]配置项默认值说明ConfigMap 名称kubernetes-dashboard-settings存储用户设置的 ConfigMap可修改参数--settings-config-map-name定义于 modules/web/pkg/args/args.go用于覆盖默认 ConfigMap 名称命名空间kubernetes-dashboard可通过--namespace参数修改2.2 API 容器API 容器需要对services/proxy拥有get权限以便从 metrics-scraper 服务获取指标数据对应模板 charts/kubernetes-dashboard/templates/rbac/api/role.yamlkind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: {{ template kubernetes-dashboard.fullname . }}-{{ .Values.api.role }} rules: # Allow Dashboard API to get metrics from metrics-scraper. - apiGroups: [ ] resources: [ services/proxy ] resourceNames: [ {{ template kubernetes-dashboard.metrics-scraper.name . }}, http:{{ template kubernetes-dashboard.metrics-scraper.name . }} ] verbs: [ get ]配置项默认值说明Service 名称kubernetes-dashboard-metrics-scrapermetrics-scraper 服务名可修改参数--metrics-scraper-service-name定义于 modules/api/pkg/args/args.go命名空间kubernetes-dashboard可通过--namespace参数修改2.3 Metrics Scraper 容器Metrics Scraper 需要对metrics.k8s.ioAPI 拥有get、list、watch权限以便从metrics-server采集指标对应模板 charts/kubernetes-dashboard/templates/rbac/metrics-scraper/clusterrole.yamlkind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: {{ template kubernetes-dashboard.fullname . }}-{{ .Values.metricsScraper.role }} rules: # Allow Metrics Scraper to get metrics from the Metrics server - apiGroups: [ metrics.k8s.io ] resources: [ pods, nodes ] verbs: [ get, list, watch ]可见Dashboard 的三个组件都以最小权限原则运行仅授予支撑自身功能所需的权限。集群管理员后续只需要把需要授权给 Dashboard 用户的权限通过 RBAC 绑定到用户凭证上即可。三、两种认证方式总览Dashboard 支持两种用户认证方式方式生效位置优先级说明Authorization Header每个请求的 HTTP 请求头最高自 1.6 版本支持请求头一旦存在将跳过登录界面Bearer TokenDashboard 登录界面—在登录界面手动粘贴 Token 进行登录两种方式的核心都是向 Kubernetes API Server 传递一个 Bearer Token区别仅在于凭证的携带位置。四、登录界面Login View使用最新安装方式时登录功能默认开启并通过 Dashboard 的网关Gateway对外暴露。用户打开 Dashboard 首页时会看到登录界面在此输入 Token 即可完成认证Kubernetes Dashboard 登录界面重要限制基于 Token 的登录仅在浏览器通过HTTPS访问界面时可用。如果访问链路是 HTTP登录会以invalid token错误失败。五、Authorization Header 认证方式5.1 原理与适用场景使用 Authorization Header 是让 Dashboard以某用户身份工作的唯一 HTTP 访问方式。做法非常简单在发给 Dashboard 的每个请求中携带Authorization: Bearer token请求头。典型落地方式是在 Dashboard 前部署反向代理由代理负责与身份提供方Identity Provider完成认证再把生成的 Token 注入到转发给 Dashboard 的请求头中。此时需要保证 Kubernetes API Server 已被正确配置为接受这些 Token。注意重要通过 API Server proxy 访问 Dashboard 时例如kubectl proxyAuthorization Header 方式不可用。原因在于请求到达 API Server 后额外的请求头会被丢弃。因此 Accessing Dashboard 中描述的kubectl port-forward方式同样无法使用 Authorization Header。5.2 快速测试可以使用 Requestly 之类的浏览器插件手动修改请求头快速验证该方式是否可行。5.3 源码级实现Authorization Header 的解析与构造实现在 modules/common/client/auth.goconst ( // authorizationHeader is the default authorization header name. authorizationHeader Authorization // authorizationTokenPrefix is the default bearer token prefix. authorizationTokenPrefix Bearer ) func HasAuthorizationHeader(req *http.Request) bool { header : req.Header.Get(authorizationHeader) if len(header) 0 { return false } token : extractBearerToken(header) return strings.HasPrefix(header, authorizationTokenPrefix) len(token) 0 } func GetBearerToken(req *http.Request) string { header : req.Header.Get(authorizationHeader) return extractBearerToken(header) }从源码可以看到三个关键点请求头必须带Bearer前缀且 Token 非空才会被认定为已认证HasAuthorizationHeaderGetBearerToken负责从请求头中剥离Bearer前缀取出 Token该 Token 会被写入面向 Kubernetes 的客户端配置中用于后续所有 API 调用。HasAuthorizationHeader的判定结果直接决定了前端是否展示登录界面——请求头一旦存在有效 Token登录界面即被跳过。5.4 客户端构建链路认证 Token 最终如何作用于 Kubernetes API 调用在 modules/common/client/client.go 的Client(request)中从每个请求动态构建客户端func Client(request *http.Request) (client.Interface, error) { if !isInitialized() { return nil, fmt.Errorf(client package not initialized) } config, err : configFromRequest(request) if err ! nil { return nil, err } if args.CacheEnabled() { return cacheclient.New( config, common.CachedClientOptions{ Token: GetBearerToken(request), ... }, ) } return client.NewForConfig(config) }即每次 HTTP 请求都会基于该请求携带的 Token 构建独立的 Kubernetes 客户端从而使不同登录用户的权限互不串扰。此外从 modules/common/client/args/args.go 可见客户端缓存默认开启--cache-enabled默认true缓存条目上限--cache-size默认 1000TTL 默认 10 分钟缓存按 Token 隔离进一步保证了多用户场景下的权限边界。5.5 登录接口实现登录接口由 auth 模块提供。路由注册于 modules/auth/pkg/routes/login/handler.gofunc init() { router.V1().POST(/login, handleLogin) }登录核心逻辑在 modules/auth/pkg/routes/login/login.gofunc login(spec *v1.LoginRequest, request *http.Request) (*v1.LoginResponse, int, error) { ensureAuthorizationHeader(spec, request) k8sClient, err : client.Client(request) if err ! nil { return nil, http.StatusInternalServerError, err } if _, err k8sClient.Discovery().ServerVersion(); err ! nil { code, err : errors.HandleError(err) return nil, code, err } return v1.LoginResponse{Token: spec.Token}, http.StatusOK, nil }有意思的是登录并非简单存下 Token而是先用该 Token 构建客户端并调用 API Server 的/version接口做一次真实连通性验证只有 Token 能被 API Server 接受认证通过登录接口才会返回成功。请求体与响应体定义在 modules/auth/api/v1/login.gotype LoginRequest struct { Token string json:token } type LoginResponse struct { Token string json:token }六、Bearer Token 认证与示例用户实战推荐先阅读 Kubernetes 官方认证文档了解如何获取可用于登录的 Token。每个 ServiceAccount 都关联着包含有效 Bearer Token 的 Secret可用于登录 Dashboard。下面演示完整流程创建一个名为admin-user的 ServiceAccount授予其集群管理员权限并获取 Token 登录 Dashboard。6.1 创建 ServiceAccount将以下清单保存到dashboard-adminuser.yamlapiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kubernetes-dashboard应用它kubectl apply -f dashboard-adminuser.yaml6.2 创建 ClusterRoleBinding大多数集群使用kops、kubeadm或其他常见工具部署中已经存在cluster-admin这个 ClusterRole因此只需为我们的 ServiceAccount 创建 ClusterRoleBinding 即可。若该 Role 不存在则需要先手动创建并授予所需权限。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kubernetes-dashboard同样通过kubectl apply -f dashboard-adminuser.yaml应用可将两份清单合并到同一文件。6.3 获取 ServiceAccount 的 Bearer Token方式一短期 Token推荐kubectl -n kubernetes-dashboard create token admin-user该命令会打印出类似如下的 Token实际为 JWT此处为演示截断值eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiw...方式二长期 Token如果需要长期有效的 Token可以手动创建一个绑定该 ServiceAccount 的 SecretToken 会被保存进 Secret 中apiVersion: v1 kind: Secret metadata: name: admin-user namespace: kubernetes-dashboard annotations: kubernetes.io/service-account.name: admin-user type: kubernetes.io/service-account-token创建后读取 Tokenkubectl get secret admin-user -n kubernetes-dashboard -o jsonpath{.data.token} | base64 -d两种方式的区别kubectl create token生成的是有时效的临时 Token带kubernetes.io/service-account-token类型与kubernetes.io/service-account.name注解的 Secret 则承载长期 Token。6.4 登录 Dashboard将得到的 Token 复制并粘贴到登录界面的Enter token输入框中点击Sign in即可完成登录在登录界面输入 Token 登录登录成功后即可看到集群总览视图此时你已拥有管理员权限登录成功后的集群总览视图注意Token 登录只在界面通过HTTPS访问时可用若网络链路是 HTTP登录会失败并报 invalid token 错误。6.5 清理与后续建议不再需要该示例用户时删除 ServiceAccount 与 ClusterRoleBindingkubectl -n kubernetes-dashboard delete serviceaccount admin-user kubectl -n kubernetes-dashboard delete clusterrolebinding admin-user关于在 Kubernetes 中授予/拒绝权限的更多细节请参阅 Kubernetes 官方认证与授权文档并按照最小权限原则为不同角色设计独立用户。七、扩展阅读用户伪装User Impersonation除上述两种认证方式外用户指南 还介绍了 User Impersonation用户伪装机制通过反向代理把用户身份信息用户名、组、附加作用域作为请求头注入Dashboard 会把这些请求头透传给 API Server。使用伪装的前提反向代理使用一个具有 RBAC 伪装权限的 ServiceAccount生成Impersonate-User请求头值为标识用户的唯一名称可选生成Impersonate-Group请求头携带用户组信息可选生成Impersonate-Extra请求头携带附加授权数据。伪装仅在反向代理提供了有效 ServiceAccount 的Authorization头时生效不适用于其他认证方式。此机制特别适合无法直接使用用户 Token 的场景例如云托管的 Kubernetes 服务。八、常见访问入口与排障提示完成认证配置后可通过以下方式访问 Dashboard详见 Accessing Dashboard方式一kubectl port-forward推荐kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong-proxy 8443:443随后访问 https://localhost:8443。方式二kubectl proxykubectl proxy --port8001随后访问http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard-kong-proxy:443/proxy/需要提醒的是通过kubectl proxy访问时 Authorization Header 方式不可用请求头会被 API Server 丢弃此时只能使用登录界面输入 Token 的方式。若访问遇到错误建议先阅读 FAQ在大多数情况下报错源于集群配置问题而非 Dashboard 本身。九、总结Kubernetes Dashboard 的访问控制设计遵循清晰的职责分离原则认证与授权全部由 Kubernetes API Server 裁决Dashboard 仅充当代理透传凭证自身 RBAC 权限被压缩到最小Authorization Header 适合反向代理集成场景但存在明文 HTTP 的 MITM 风险且无法在kubectl proxy路径下使用Bearer Token 登录是交互式场景的首选配合 ServiceAccount RBAC 绑定即可精确控制每个登录用户在 Dashboard 中看到与操作的资源范围通过kubectl create token短期或 service-account-token Secret长期即可获取登录凭证全程有源码层实现可验证。附涉及的关键文件索引内容仓库路径访问控制主文档docs/user/access-control/README.md示例用户创建指南docs/user/access-control/creating-sample-user.md访问 Dashboard 指南docs/user/accessing-dashboard/README.mdWeb 容器 Rolecharts/kubernetes-dashboard/templates/rbac/web/role.yamlAPI 容器 Rolecharts/kubernetes-dashboard/templates/rbac/api/role.yamlMetrics Scraper ClusterRolecharts/kubernetes-dashboard/templates/rbac/metrics-scraper/clusterrole.yaml登录核心逻辑modules/auth/pkg/routes/login/login.go登录接口路由modules/auth/pkg/routes/login/handler.go登录请求/响应模型modules/auth/api/v1/login.goAuthorization Header 实现modules/common/client/auth.go请求级客户端构建modules/common/client/client.go设置 ConfigMap 参数modules/web/pkg/args/args.gometrics-scraper 服务名参数modules/api/pkg/args/args.go赞分享前端后端云原生【免费下载链接】dashboardGeneral-purpose web UI for Kubernetes clusters项目地址https://gitcode.com/gh_mirrors/da/dashboard点击查看免费下载相关推荐Gramophone重新定义Android音乐播放体验的智能播放器Gramophone重新定义Android音乐播放体验的智能播放器 你是否厌倦了臃肿复杂的音乐播放器Gramophone正是你寻找的答案——这款基于AndrAuthelia 访问控制Access Control / RBAC配置完全指南规则、策略与正则匹配实战Authelia 访问控制Access Control / RBAC配置完全指南规则、策略与正则匹配实战 导读 Access Control 是 Auth后端认证鉴权单点登录身份认证应用安全Kubernetes Dashboard安全实践RBAC与访问控制详解Kubernetes Dashboard安全实践RBAC与访问控制详解 本文深入探讨了Kubernetes Dashboard的安全架构重点分析了默认权限配前端后端云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考