• 认证
  • Service Accounts
• 授权（RBAC）
  • Role
  • ClusterRole
  • RoleBinding
  • ClusterRoleBinding

认证

所有 Kubernetes 集群有两类用户：由 Kubernetes 管理的 Service Accounts (opens new window) （服务账户）和（Users Accounts） 普通账户。

普通账户是假定被外部或独立服务管理的，由管理员分配 keys，用户像使用 Keystone 或 google 账号一样，被存储在包含 usernames 和 passwords 的 list 的文件里。

需要注意：在 Kubernetes 中不能通过 API 调用将普通用户添加到集群中。

• 普通帐户是针对（人）用户的，服务账户针对 Pod 进程
• 普通帐户是全局性。在集群所有namespaces中，名称具有惟一性
• 通常，群集的普通帐户可以与企业数据库同步，新的普通帐户创建需要特殊权限。服务账户创建目的是更轻量化，允许集群用户为特定任务创建服务账户
• 普通帐户和服务账户的审核注意事项不同
• 对于复杂系统的配置包，可以包括对该系统的各种组件的服务账户的定义

Service Accounts

Service Account Admission Controller

通过 Admission Controller (opens new window) 插件来实现对 pod 修改，它是 apiserver 的一部分。创建或更新 pod 时会同步进行修改 pod。当插件处于激活状态（在大多数发行版中都默认情况）创建或修改 pod 时，会按以下操作执行：

• 如果 pod 没有设置 ServiceAccount，则将 ServiceAccount 设置为 default
• 确保 pod 引用的 ServiceAccount 存在，否则将会拒绝请求
• 如果 pod 不包含任何 ImagePullSecrets，则将 ServiceAccount 的 ImagePullSecrets 会添加到 pod 中，即将 ImagePullSecrets 的验证交给 ServiceAccount，然后 Pod 只和 ServiceAccount 交互
• 为包含 API 访问的 Token 的 pod 添加了一个 volume
• 把 volumeSource 添加到安装在 pod 的每个容器中，挂载在 /var/run/secrets/kubernetes.io/serviceaccount

Token Controller

TokenController 作为 controller-manager 的一部分运行。异步行为:

• 观察 serviceAccount 的创建，并创建一个相应的 Secret 来允许 API 访问
• 观察 serviceAccount 的删除，并删除所有相应的 ServiceAccountToken Secret
• 观察 secret 添加，并确保关联的 ServiceAccount 存在，并在需要时向 secret 中添加一个 Token
• 观察 secret 删除，并在需要时对应 ServiceAccount 的关联

Service Account Controller

Service Account Controller 在 namespaces 里管理 ServiceAccount，并确保每个有效的 namespaces 中都存在一个名为 default 的 ServiceAccount。

授权（RBAC）

RBAC：基于角色的权限控制。

Role

代表一个角色，会包含一组权限，没有拒绝规则，只是附加允许。它是 Namespace 级别的资源，只能作用与 Namespace 之内。

# 查看已有的角色信息
kubectl get role -n ingress-nginx -o yaml

配置文件：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  name: nginx-ingress
  namespace: ingress-nginx
rules: # 规则
- apiGroups:
  - ""
  resources: # 权限控制的资源
  - configmaps
  - pods
  - secrets
  - namespaces
  verbs: # 可以执行的权限
  - get
- apiGroups:
  - ""
  resourceNames:
  - ingress-controller-label-nginx
  resources:
  - configmaps
  verbs:
  - get
  - update
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - create

ClusterRole

功能与 Role 一样，区别是 ClusterRole 资源类型为集群类型，而 Role 只在 Namespace。

# 查看某个集群角色的信息
kubectl get clusterrole view -o yaml

RoleBinding

Role 或 ClusterRole 只是用于制定权限集合，具体作用与什么对象上，需要使用 RoleBinding 来进行绑定。

作用于 Namespace 内，可以将 Role 或 ClusterRole 绑定到 User、Group、Service Account 上。

# 查看 rolebinding 信息
kubectl get rolebinding --all-namespaces

# 查看指定 rolebinding 的配置信息
kubectl get rolebinding <role_binding_name> --all-namespaces -o yam

配置文件：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  # ......
roleRef: # 绑定的角色
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects: # 绑定的资源主体，一般在 Deployment 配置文件会配置一个 ServiceAccount
- kind: ServiceAccount
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx

ClusterRoleBinding

与 RoleBinding 相同，但是作用于集群之上，可以绑定到该集群下的任意 User、Group 或 Service Account。