身份认证与权限

Kubernetes 中提供了良好的多租户认证管理机制，如 RBAC、ServiceAccount 还有各种策略等。
通过该文件可以看到已经配置了 RBAC 访问控制
/usr/lib/systemd/system/kube-apiserver.service

一、认证

所有 Kubernetes 集群有两类用户：由 Kubernetes 管理的Service Accounts （服务账户）和（Users Accounts） 普通账户。
普通账户是假定被外部或独立服务管理的，由管理员分配 keys，用户像使用 Keystone 或 google 账号一样，被存储在包含 usernames 和 passwords 的 list 的文件里。
需要注意：在 Kubernetes 中不能通过 API 调用将普通用户添加到集群中。

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

一）User Accounts

二）Service Accounts

标识这个服务对应多少权限

1、Service Account 自动化

Service Account Admission Controller

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

1. 如果 pod 没有设置 ServiceAccount，则将 ServiceAccount 设置为 default。
2. 确保 pod 引用的 ServiceAccount 存在，否则将会拒绝请求。
3. 如果 pod 不包含任何 ImagePullSecrets，则将ServiceAccount 的 ImagePullSecrets 会添加到 pod 中。
4. 为包含 API 访问的 Token 的 pod 添加了一个 volume。
5. 把 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）

Role-Based Access Control

一）Role

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

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

配置文件

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
roles:
- 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 一样，区别是资源类型为集群类型，而 Role 只在 Namespace

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

三）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 -oyaml

配置文件

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  ......
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name nginx-ingress-role
subjects:
- kind: ServiceAccount
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx

四）ClusterRoleBinding

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