当前位置：首页 > news >正文

【Kubernetes】身份认证与鉴权

news 2025/6/29 21:47:33

一，认证

所有 Kubernetes 集群有两类用户：由Kubernetes管理的ServiceAccounts(服务账户)和(Users Accounts)普通账户。

两种账户的区别：

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

1，User Accounts

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

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

2，Service Accounts

# 获取Service Accounts
kubectl get serviceaccount 或者 [sa]

自动化的三种控制器：

2.1 Service Account Admission Controller

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

如果 pod 没有设置 serviceAccount，则将 ServiceAccount设置为 default。
确保 pod 引用的 ServiceAccount 存在，否则将会拒绝请求。
如果 pod 不包含任何 ImagePullsecrets，则将ServiceAccount的 lmagePullsecrets 会添加到 pod 中。
为包含 API访问的 Token 的 pod 添加了一个 volume。
把 volumesource 添加到安装在 pod 的每个容器中，挂载在/var/run/secrets/kubernetes.io/serviceaccount.

2.2 Token Controller

2.3 Service Account Controller

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

二，授权（RBAC）

角色：Role

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

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

在这里插入图片描述

集群角色：ClusterRole

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

# 查看某个集群角色的详细信息
kubectl get clusterrole [集群名] -o yaml

角色绑定：RoleBinding

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

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

#查看 rolebinding 信息
kubectl get rolebinding --all-namespaces
或
kubectl get rolebinding -A#查看指定 rolebinding 的配置信息
kubectl get rolebinding <role_binding_name> --all-namespaces -oyaml
或
kubectl get rolebinding <role_binding_name> -A -oyaml