Apr 7, 2024

Authorization

cgxxv

kuberneteskube security

192 Words | 52 Seconds

2024-04-07 12:03 +0800

kubernetes 内置 RBAC，ABAC，Node Authorization 等授权模式，然后使用kube-apiserver --authorization-mode=<AUTH MODE>,RBAC开启对应的授权模式，其中 RBAC 是必选项。

RBAC

rbac

基于角色的访问控制，通过集群管理员指定用户拥有的权限，使用时经过授权模块赋予对应的权限。

支持权限的降级，但不支持权限的升级，如 RoleBinding（作用域为 namespace）可以绑定到 ClusterRole，但是不能将 ClusterRoleBinding（作用域为 cluster）绑定到 Role。

对于普通用户名或用户组的限制，其中前缀是system:为 kubernetes 系统保留的，禁止用户使用前缀为此的用户名称或组名称。

对于服务账户和服务账户组，分别需要包含system:serviceaccount:和system:serviceaccounts:前缀。

对于需要修改用户或组的 RoleBinding 或者 ClusterRoleBinding，系统不支持修改，需要删除后重新添加。

默认的 Roles 和 RoleBindings

对集群默认角色、名称、以及绑定关系的修改，都将可能导致集群无法工作，需要格外小心。

  1. 集群中以system:为前缀的，用以标识对应资源是直接由集群控制面管理的。
  2. 所有默认的 ClusterRole 和 ClusterRoleBinding 都有kubernetes.io/bootstrapping=rbac-defaults标签
  3. 自动协商机制保证，每次集群启动时，kube-apiserver 都会更新默认 ClusterRole 以添加各类缺失的权限，并更新 ClusterRoleBinding 以添加各类缺失的主体，可修复一些不小心发生的修改，并有助于保证角色和角色绑定在新的发行版中保持最新状态。

kube-apiserver 发现角色

默认的角色绑定赋予所有人（包括匿名用户）可以访问对于被集群认为是安全公开的 API，如果要禁用匿名用户访问可以配置kube-apiserver --anonymous-auth=false。

默认 ClusterRole 默认 ClusterRoleBinding 说明
system:basic-user system:authenticated 组 允许用户以只读的方式去访问他们自己的基本信息。在 v1.14 之前，默认也绑定 system:unauthenticated
system:discovery system:authenticated 组 允许以只读方式访问 API 发现端点，这些端点用来发现和协商 API 级别。v1.14 之前，默认也绑定 system:unauthenticated
system:public-info-viewer system:authenticated, system:unauthenticated 组 允许对集群的非敏感信息进行只读访问，此角色在 v1.14 中引入

默认的面向用户的角色

如cluster-admin是系统超级管理员角色，cluster-status是 ClusterRoleBinding 在集群范围内完成授权的角色，admin、edit、view是使用 RoleBinding 在特定名字空间内授予的角色

ClusterRole ClusterRoleBinding 说明
cluster-admin system:masters 集群超级用户角色，允许对集群上的任何资源执行任何操作
admin 无 允许管理员访问权限，旨在使用 RoleBinding 在名字空间内执行授权。不允许对资源配额或者名字空间本身进行写操作。不允许对 v1.22+ 创建的 EndpointSlices(或 Endpoints)进行写操作，EndpointSlices 和 Endpoints 写权限
edit 无 允许对名字空间的大多数对象进行读写操作。可以访问 Secret，可以访问以 ServiceAccount 身份运行的 Pod。不允许对 v1.22+创建的 EndpointSlices（或 Endpoints）对象进行写操作
view None 允许对名字空间的大多数对象有只读权限。不允许查看角色或角色绑定，不允许查看 Secret，因为读取 Secret 的内容意味着可以访问名字空间中的 ServiceAccount 的 Token 信息，进而允许利用该 Token 访问 API，从而间接权限提升

Core component roles

ClusterRole ClusterRoleBinding Description
system:kube-scheduler system:kube-scheduler 允许访问 scheduler 组件所需的资源
system:volume-scheduler system:kube-scheduler 允许访问 kube-scheduler 组件所需要的卷资源
system:kube-controller-manager system:kube-controller-manager 允许访问控制器管理器所需要的资源。控制器角色
system:node none 允许访问 kubelet 所需要的资源，包括对所有 Secret 的读权限和对所有 Pod 状态对象的写权限。用户应该使用Node 鉴权组件和NodeRestriction 准入插件而不是 system:node 角色。同时基于 kubelet 上调度执行的 Pod 来授权 kubelet 对 api 的访问。该角色仅仅是为了兼容 v1.8 之前的版本。

服务账户权限

默认的 RBAC 策略为控制面组件、节点和控制器授予权限，但不会对 kube-system 以外的服务账户授予权限，除了授予所有已认证用户的发现权限。

从最安全到最不安全的服务账户权限配置，推荐顺序如下：

  1. 为特定应用的服务账户授予角色
  2. 将角色授予某名字空间中的 default 服务账户，如果没有指定服务账户，将使用默认的 default 服务账户
  3. 将角色授予名字空间中所有服务账户
  4. 在集群范围内为所有服务账户授予一个受限角色（不推荐）
  5. 授予超级用户访问权限给集群范围内的所有服务账户（强烈不推荐）

ABAC

基于属性的访问控制

使用 Node 授权

该方式是专门针对 kubelet 发出的 API 请求进行授权

See Also