【Linux39-15】k8s API 访问控制（ sa+ua 认证、RBAC授权、准入控制）

---

一、Kubernetes API 访问控制

【k8s访问控制官方文档：https://kubernetes.io/zh/docs/concepts/security/controlling-access/】

用户使用 kubectl、客户端库或构造 REST 请求来访问 Kubernetes API。 人类用户和 Kubernetes 服务账户都可以被鉴权访问 API。 当请求到达 API 时，它会经历多个阶段，如下图所示：

访问控制过程：

1.1 认证

认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。通常启用 X509 Client Certs 和 Service Accout Tokens 两种认证方式。

Kubernetes集群有两类用户：（由Kubernetes管理）

• Service Accounts （服务账户）
• Users Accounts（普通账户）

k8s中账号的概念不是我们理解的账号，它并不真的存在，它只是形式上存在。

UserAccount	serviceAccount
针对人而言的	针对运行在 pod 中的进程而言的
用户账户是全局性的。 其名称在集群各 namespace 中都是全局唯一的,未来的用户资源不会做 namespace 隔离	服务账户是 namespace 隔离的
通常情况下,集群的用户账户可能会从企业数据库进行同步,其创建需要特殊权限,并且涉及到复杂的业务流程。	服务账户创建的目的是为了更轻量,允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )

1.2 授权

必须经过认证阶段，才到授权请求，根据所有授权策略匹配请求资源属性，决定允许或拒绝请求。

授权方式现共有6种：AlwaysDeny、AlwaysAllow、ABAC、RBAC、Webhook、Node。

默认集群强制开启RBAC。

1.3 准入控制

用于拦截请求的一种方式,运行在认证、授权之后，是权限认证链上的最后一环，对请求API资源对象进行修改和校验。

请求通过所有准入控制器后，将使用检验例程检查对应的 API 对象，然后将其写入对象存储（如图1步骤 4 所示）

二、认证

2.1 serviceAccount 不安全示例

1）创建secret，名称为myregistrykey（能访问Harbor仓库的所有项目）

# 创建secret
kubectl create secret docker-registry myregistrykey --docker-server=zy.westos.org --docker-username=admin --docker-password=westos --docker-email=zy@westos.org

2）将secret直接写在pod文件中，但是不安全（调度节点的镜像为Harbor仓库的非公开项目）

# pod.yml
apiVersion: v1
kind: Pod
metadata:name: gamelabels:app: game
spec:containers:- name: gameimage: zy.westos.org/westos/game2048imagePullSecrets:- name: myregistrykey

2.2 创建 serviceAccount

【服务账户官方文档：https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-service-account/】

1）创建 sa：admin（这时的admin的信息为k8s自动生成的认证信息，但没有授权）

2）创建 镜像拉取secret，名称为myregistrykey（能访问Harbor仓库的所有项目）

# 创建secret
kubectl create secret docker-registry myregistrykey --docker-server=zy.westos.org --docker-username=admin --docker-password=westos --docker-email=zy@westos.org

3）添加 镜像拉取secrets 到 serviceAccount 中

把认证信息直接添加到sa中，要比直接在pod中指定imagePullSecrets要安全

# 添加认证
kubectl patch serviceaccount admin -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'

4）在pod中绑定sa（所需镜像为Harbor仓库的非公开项目）

apiVersion: v1
kind: Pod
metadata:name: gamelabels:app: game
spec:containers:- name: gameimage: zy.westos.org/westos/game2048ports:- name: httpcontainerPort: 80serviceAccountName: admin

2.3 创建 userAccount

【用户认证官方文档：https://kubernetes.io/zh/docs/reference/access-authn-authz/authentication/】
【证书制作官方文档：https://kubernetes.io/zh/docs/concepts/cluster-administration/certificates/】
【证书签名请求官方文档：https://kubernetes.io/zh/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user】

1）创建 X509证书

1.生成PKI密钥位数为 2048 的 test.key：
cd /etc/kubernetes/pki/
openssl genrsa -out test.key 20482.生成证书签名请求：（"/CN=bob"确定用户名）
openssl req -new -key test.key -out test.csr -subj "/CN=test"3.生成服务器证书（使用 -days 参数来设置证书有效时间）
openssl  x509 -req -in test.csr -CA ca.crt -CAkey ca.key  -CAcreateserial -out test.crt -days 3654.查看证书：
openssl x509 -in test.crt -text -noout

2）将这个用户添加到 kubeconfig 文件

kubectl config set-credentials test --client-certificate=/etc/kubernetes/pki/test.crt --client-key=/etc/kubernetes/pki/test.key --embed-certs=true
# 查看
kubectl config view

3）添加上下文

kubectl config set-context test@kubernetes --cluster=kubernetes --user=test

4）切换上下文为 test

kubectl config use-context test@kubernetes

5）测试：此时用户 test 通过认证，但还没有权限操作集群资源，需要继续添加授权。

6）切换上下文到管理员（在执行部署文件时需要切换成管理员，即kubernetes-admin）

三、RBAC授权（基于角色的访问控制）

【RBAC官方文档：https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/】

允许管理员通过Kubernetes API动态配置授权策略。RBAC就是用户通过角色与权限进行关联。

RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即可。

RBAC的三个基本概念 :

• Subject:被作用者,它表示k8s中的三类主体, user, group, serviceAccount
• Role:角色,它其实是一组规则,定义了一组对 Kubernetes API 对象的操作权限。
• RoleBinding:定义了“被作用者”和“角色”的绑定关系。
  
  

RBAC的四种 Kubernetes 对象：

• Role：角色（是一系列的权限的集合，Role只能授予单个 namespace 中资源的访问权限）
• ClusterRole：集群角色（定义集群范围的角色）
• RoleBinding：角色绑定（对某个namespace 内授权），将Role中定义的权限授予给用户或用户组。它包含一个subjects列表(users,groups ,service accounts)，并引用该Role。
• ClusterRoleBinding：集群角色绑定（适用在集群范围内执行授权）

3.1 Role 及 RoleBinding 示例

• 在执行部署文件时需要切换上下文为管理员，即 kubernetes-admin
  
  

1）创建一个位于 “default” 名字空间的 Role 的示例，可用来授予对 pods 的读访问权限

# role.yml 
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:namespace: defaultname: myrole
rules:
- apiGroups: [""] # "" 标明 core API 组resources: ["pods"]verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]

2）创建RoleBinding 将 “myrole” Role 授予在 “default” 名字空间中的用户 “test”。（即用户 “test” 就具有了读取 “default” 名字空间中 pods 的权限）

# roleBinding.yml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: test-read-podsnamespace: default
subjects:
# 可以指定不止一个“subject（主体）”
- kind: Username: test # "name" 是不区分大小写的apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系kind: Role # 此字段必须是 Role 或 ClusterRolename: myrole # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配apiGroup: rbac.authorization.k8s.io

3）切换上下文为 test，测试结果：具有了读取 “default” 名字空间中 pods 的权限

4）但是 test 并不具有读取其他命名空间的 pods 权限，最后切换上下文为管理员

3.2 ClusterRole 示例

ClusterRole 可以和 Role 相同完成授权。 因为 ClusterRole 属于集群范围，所以它也可以为以下资源授予访问权限：

• 集群范围资源（比如 节点（Node））
• 非资源端点（比如 /healthz）
• 跨名字空间访问的名字空间作用域的资源（如 Pods），比如，你可以使用 ClusterRole 来允许某特定用户执行 kubectl get pods --all-namespaces
  
  

示例：

1）创建 ClusterRole（可以读取任何一个命名空间的 pods 及 deployments）

# clusterRole.yml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:# "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制name: myclusterrole
rules:
- apiGroups: [""]resources: ["pods"]verbs: ["get", "watch", "list", "delete", "create", "update"]
- apiGroups: ["extensions", "apps"]resources: ["deployments"]verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

3.2.1 RoleBinding（指定namespace授权）

RoleBinding 也可以引用 ClusterRole，以将对应 ClusterRole 中定义的访问权限授予 RoleBinding 所在名字空间的资源。这种引用使得你可以跨整个集群定义一组通用的角色， 之后在多个名字空间中复用。

1）创建RoleBinding（获得 ClusterRole 制定的权限，但是只针对 RoleBinding 指定的命名空间）

# roleBinding.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: rolebind-myclusterrolenamespace:  default
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.iokind: Username: test

2）测试权限：切换上下文为 test ，发现只针对 RoleBinding 指定的命名空间

3）最后切换上下文为管理员

kubectl config use-context kubernetes-admin@kubernetes

3.2.2 ClusterRoleBinding（跨集群授权）

ClusterRoleBinding：跨整个集群完成访问权限的授予

1）创建 ClusterRoleBinding

# clusterRoleBinding.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: clusterrolebinding-myclusterrole
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.iokind: Username: test

2）测试权限：切换上下文为 test ，可以读取整个集群的pod权限

3）最后切换上下文为管理员

kubectl config use-context kubernetes-admin@kubernetes