K8s-认证机制:ServiceAccounts
K8s-认证机制:ServiceAccounts
K8s的认证方式
- 客户端证书
- 传入HTTP头中的token
- 基础的HTTP认证
- 其他
用户和组
用户
就是通过单个的SA的认证
组别
用户和SA可以属于一个或者多个组。
内置的用户组:
system unauthenticated 组用于所有认证插件都不会认证客户端身份的 请求
system authent cated 组会自动分配给一个成功通过认证的用户
system:serviceaccounts 组包含所有在系统中的 Serv iceAccount
system serviceaccounts <口 amespace >组包含了所有在特定命名空 间中的 Serv ceAccount
什么是SA
一个SA的用户名格式如下:
system: serviceaccount:<namespace >:
Pod中sa的位置: /var/run/secrets/kube netes io/serv ceaccount/token
每一个Namespace都有一个默认的ServiceAccount
RBAC
K8s的RBAC主要通过Role
和ClusterRole
,RoleBinding
和ClusterRoleBinding
来实现
Role
YAMl
apiVersion: rbac.authorization.k8s.io/v1 |
SHELL
kubectl create role service-reader --verb=get --verb=list |
Rolebinding
YAML
apiVersion: rbac.authorization.k8s.io/v1 |
SHELL
kubectl create rolebinding test --role=service-reader |
ClusterRole
集群级别的资源访问
YAML
#ClusterRoles 是给全命名空间的 |
ClusterRoleBinding
YAML
Role和binding 的组合排列
访问的资源 | 使用的角色类型 | 使用的绑定类型 |
---|---|---|
集群级别资源(Nodes、PV) | ClusterRole | ClusterRoleBinding |
非资源型URL(/api,/healthz) | ClusterRole | ClusterRoleBinding |
在任何命名空间的资源(跨NameSpace资源) | ClusterRole | ClusterRoleBinding |
在具体的命名空间中的资源(在多个命名空间中重用这个相同的ClusterRole) | ClusterRole | RoleBinding |
在具体的命名空间的资源(Role中定以好) | Role | RoleBinding |
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 Joohwan!
评论