Kubernetes 访问控制

最后更新: 2022-06-27 04:47:20 +0800 +0800
原文以英文撰写。您正在阅读AI翻译版本。

Kubernetes 通过身份认证、授权和准入控制处理 API 请求。身份认证建立身份;授权决定该身份是否可以执行某项操作;准入控制可以验证或修改被接受的对象。这些是彼此独立的控制,应分别配置和审计。

使用 OIDC 进行身份认证 #

OpenID Connect(OIDC)允许 API 服务器验证外部身份提供商签发的持有者令牌。API 服务器配置发行者 URL、客户端 ID,以及可选的用户名和组声明映射。API 服务器必须能够访问发行者,并且发行者的 TLS 证书必须通过验证。

身份提供商负责用户生命周期和多因素身份认证;Kubernetes 从有效令牌中接收用户名和组。不要为人员使用共享的静态令牌。在 kubectl 中使用获批准的 OIDC 登录插件或 exec 凭据提供商,从而刷新短期令牌,而无需在 kubeconfig 文件中存储长期凭据。

使用 RBAC 进行授权 #

RBAC 通过 Role 和 ClusterRole 对象授予资源类型上的动词权限,再通过绑定附加这些权限。Role 的作用域是命名空间;ClusterRole 可以授予集群范围的访问权限,也可以在命名空间内绑定。

yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployment-reader
  namespace: payments
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developers-can-read-deployments
  namespace: payments
subjects:
  - kind: Group
    name: payments-developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: deployment-reader
  apiGroup: rbac.authorization.k8s.io

只授予所需的最小动词、资源、命名空间和非资源 URL。除非用于严格控制的平台管理,否则应避免 cluster-admin、通配符动词和通配符资源。使用 kubectl auth can-i 检查拟授予的权限。

控制资源与服务账户 #

ResourceQuota 限制命名空间的资源总消耗;LimitRange 为每个容器提供或约束 requests 和 limits。仅有配额并不能保证公平调度:工作负载应指定 CPU 和内存 requests,命名空间也需要运行监控。

服务账户是工作负载的身份。在不需要时禁用自动令牌挂载,使用投影的短期令牌,并将每个工作负载服务账户绑定到最小角色。绝不要向应用授予默认服务账户的广泛权限。准入策略、Pod 安全标准、网络策略和镜像控制可以补充 RBAC,但都不能取代它。

评论

在 GitHub 上阅读或评论(发表评论需要登录)