K8s 身份认证和权限

K8s 身份认证和权限

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中，名称具有惟一性。
• 通常，群集的普通帐户可以与企业数据库同步，新的普通帐户创建需要特殊权限。服务账户创建目的是更轻量化，允许集群用户为特定任务创建服务账户。
• 普通帐户和服务账户的审核注意事项不同。
• 对于复杂系统的配置包，可以包括对该系统的各种组件的服务账户的定义。

Service Accounts

服务账号以 ServiceAccount 对象的形式存在于 API 服务器中。服务账号具有以下属性：

• 名字空间限定： 每个服务账号都与一个 Kubernetes 名字空间绑定。 每个名字空间在创建时，会获得一个名为 default 的 ServiceAccount。

• 轻量级： 服务账号存在于集群中，并在 Kubernetes API 中定义。你可以快速创建服务账号以支持特定任务。

• 可移植性： 复杂的容器化工作负载的配置包中可能包括针对系统组件的服务账号定义。 服务账号的轻量级性质和名字空间作用域的身份使得这类配置可移植。

服务账号与用户账号不同，用户账号是集群中通过了身份认证的人类用户。默认情况下， 用户账号不存在于 Kubernetes API 服务器中；相反，API 服务器将用户身份视为不透明数据。 你可以使用多种方法认证为某个用户账号。某些 Kubernetes 发行版可能会添加自定义扩展 API 来在 API 服务器中表示用户账号。

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

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

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

demo文件

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

demo

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

ClusterRoleBinding

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

注：这块内容更多是需要运维人员去处理，对于开发，有一定理论基础即可，后期要用再深究吧