循序渐进kubernetes-RBAC(Role-Based Access Control)

文章目录

概要
Kubernetes API
了解 Kubernetes 中的 RBAC
Roles and Role Bindings:
ClusterRoles and ClusterRoleBindings
检查访问权限：
外部用户
结论

概要

Kubernetes 是容器化应用的强大引擎，但仅仅关注部署和扩展远远不够，集群的安全同样至关重要。这时，角色权限控制（Role-Based Access Control，RBAC）就派上了用场。本文将深入了解 Kubernetes RBAC，帮助您构建精细化的安全策略，并通过实例详细展示其工作原理。

Kubernetes API

在介绍 RBAC 之前，需要明确授权模型在整个架构中的位置。
以下是向 Kubernetes 集群提交一个 Pod 的示例：

cat <<EOF |kubectl apply -f  -
apiVersion: v1
kind: Pod
metadata:name: nginxnamespace: web
spec:serviceAccountName: johncontainers:- image: nginxname: nginxports:- containerPort: 8080
EOF

部署Pod 到集群：

kubectl apply -f pod.yaml

运行 kubectl apply 时，会依次执行以下步骤：

从 KUBECONFIG 文件中读取配置信息。
查询 API 以发现可用的 API 和对象。
在客户端验证资源，检查是否存在明显错误。
将包含资源定义的请求发送到 kube-apiserver。
当 kube-apiserver 接收到请求时，不会立即将其存储到 etcd 中。
首先，会对请求的合法性进行验证，即对请求进行身份认证。
通过身份认证后，还会检查请求是否具备创建资源的权限。

身份和权限是两个独立的概念。
即使拥有集群访问权限，也不一定能够创建或读取所有资源。
授权通常通过基于角色的访问控制（RBAC）实现。
RBAC 提供细粒度的权限控制，用于限制用户或应用程序的操作范围。

从实际操作的角度来看，API 服务器按以下顺序执行操作：

A. 验证用户身份
如果身份验证失败，返回 401 Unauthorized 并拒绝请求。
如果身份验证通过，进入下一阶段。
B. 检查用户权限
如果用户无权访问资源，返回 403 Forbidden 并拒绝请求。
如果用户具备权限，继续处理请求。
通过 RBAC 角色实现用户与权限的解耦

RBAC 是一种基于组织中用户角色分配资源访问权限的模型。
为更直观地理解其工作原理，可以设想从零设计一个授权系统。
要确保用户对特定资源具有写入权限，可以采用一种简单的实现方式，即创建一个包含三列的列表，例如：

| User   | Permission | Resource |
| ------ | ---------- | -------- |
| John   | read+write | app1     |
| Emily  | read       | app2     |
| Michael| read       | app2     |

在此示例中：

John 拥有对 app1 的读写权限，但无法访问 app2。
Emily 和 Michael对 app2 仅拥有读取权限，但无法访问 app1。
当用户和资源数量较少时，这种表格形式可以正常使用，但随着规模扩大，可能会显现一些局限性。

例如，如果将 Michael和 Emily 归为同一团队，并授予其对 app1 的读取权限，表中将需要新增以下条目：

| User   | Permission | Resource   |
| ------ | ---------- | ---------- |
| John   | read+write | app1       |
| Emily  | read       | app2       |
| Michael| read       | app2       |
| Emily  | read       | app1       |
| Michael| read       | app1       |

这种设计难以直接体现 Emily和 Michael因同属一个团队而拥有相同访问权限的关系。
在这里插入图片描述
可以通过在表中添加“Team”列来解决此问题，但更优的方式是拆分这些关系：

定义一个通用的权限容器，即角色（Role）。
不直接将权限分配给用户，而是将权限包含在反映其在组织中角色的角色中。
最后，将角色与用户关联起来。

可以通过以下方式进行改进：

不再使用单一表格，而是将结构拆分为两个表格：
第一个表格将权限映射到角色。
第二个表格将角色与身份关联起来。

| Role   | Permission | Resource   |
| ------ | ---------- | ---------- |
|admin   | read+write | app1       |
|viewer  | read       | app2       || User   | Role      | 
| ------ | ----------|
|John    | admin     | 
|Emily   | viewer    | 
|Michael | viewer    |

当需要将 Mo 设置为 app1 的管理员时，可以通过以下方式将角色分配给用户：

| User   | Role            | 
| ------ | ----------------|
|John    | admin           | 
|Emily   | reviewer        | 
|Michael | viewer,admin    |

通过使用角色将用户与权限解耦，可以简化大型组织中涉及众多用户和权限的安全管理。
在这里插入图片描述

了解 Kubernetes 中的 RBAC

Kubernetes (K8s) 中的 RBAC（基于角色的访问控制）是一种安全机制，用于定义和实施对集群中各类资源的细粒度访问控制策略，是管理和保护 Kubernetes API 服务器及集群资源访问的重要组成部分。
RBAC 通过定义角色（Role）和角色绑定（Role Binding），用于指定对特定 Kubernetes 资源（如 Pod、Service、ConfigMap）及命名空间级别允许执行的action（verbs）。以下是 RBAC 的一些核心概念：

角色（Roles）：角色是定义在特定命名空间内，允许对某个资源执行的操作集合。例如，可以创建一个角色，允许在特定命名空间中对 Pod 执行读取和列出操作。
角色绑定（Role Bindings）：角色绑定将角色与一个或多个用户、组或服务账户关联，指定哪些主体可以执行角色中定义的操作。例如，可以将角色绑定到特定用户或用户组。
集群角色（ClusterRoles）：与角色仅限于单一命名空间不同，集群角色不受命名空间限制。集群角色定义了对集群级资源（如节点或持久卷）执行的操作。
集群角色绑定（ClusterRoleBindings）：集群角色绑定将集群角色与用户、组或服务账户关联，类似于角色绑定。它们确定哪些主体可以访问所有命名空间中的集群级资源。

通过使用 RBAC，可以创建一个细粒度的访问控制系统，符合组织的安全需求。这确保了用户、应用程序和服务拥有执行任务所需的适当访问权限，同时保持 Kubernetes 集群的整体安全。

基于角色的访问控制（Role-Based Access Control）是防止未经授权访问的保护屏障！这种安全机制可以为 Kubernetes 资源创建高度精细的访问策略。通过它，可以为用户、应用程序和服务分配恰到好处的权限，同时确保集群的安全性不受威胁。

Roles and Role Bindings:

角色（Roles）用于为命名空间中的特定资源定义访问策略。角色绑定（Role Bindings）将角色与用户、用户组或服务账户关联，明确访问权限的分配关系。
示例：
1.首先创建一个service account

cat <<EOF|kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:name: johnnamespace: web
EOF

2.定义一个名为“pod-reader-role”的角色。

cat <<EOF |kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: webname: pod-reader-role
rules:
- apiGroups: [""]resources: ["pods"]verbs: ["get", "list"]

说明：
此 YAML 文件定义了一个名为 “pod-reader-role” 的角色，适用于 “web” 命名空间，授权对 “pods” 执行 “get” 和 “list” 操作。
3.定义一个名为“pod-reader-role-binding”的角色绑定，并将其绑定到“web”命名空间中的服务用户“john”。

cat <<EOF |kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: pod-reader-role-bindingnamespace: web
subjects:
- kind: ServiceAccountname: johnapiGroup: rbac.authorization.k8s.io
roleRef:kind: Rolename: pod-reader-roleapiGroup: rbac.authorization.k8s.io
EOF

说明：
该 YAML 文件创建了一个名为 “pod-reader-role-binding” 的角色绑定（Role Binding），将 “pod-reader-role” 角色与 “web” 命名空间中的用户 “john” 关联起来。用户 “john” 现在拥有了 “pod-reader-role” 的权限。

ClusterRoles and ClusterRoleBindings

集群角色（ClusterRoles）和集群角色绑定（ClusterRoleBindings）将 RBAC 扩展至整个集群，允许对集群级资源的访问权限进行管理。
1.定义一个名为“node-reader-cluster-role”的clusterrole

cat <<EOF |kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: node-reader-cluster-role
rules:
- apiGroups: [""]resources: ["nodes"]verbs: ["get", "list"]
EOF

说明：
ClusterRole 定义了集群范围内的权限，用于控制对 Kubernetes 集群中资源的访问。上面的 YAML 文件定义了一个名为 “node-reader-cluster-role” 的 ClusterRole，允许对 “nodes” 资源执行 “get” 和 “list” 操作，用于读取节点信息。
2.定义一个名为“node-reader-cluster-binding”的集群角色绑定，并将其绑定到服务用户“admin”。

cat <<EOF |kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: node-reader-cluster-binding
subjects:
- kind: ServiceAccountname: adminapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: node-reader-cluster-roleapiGroup: rbac.authorization.k8s.io
EOF

说明：
在这个 YAML 文件中，名为“node-reader-cluster-binding”的集群角色绑定将“node-reader-cluster-role”集群角色与集群级的用户“admin”关联起来。通过这个绑定，用户“admin”获得了“node-reader-cluster-role”集群角色中定义的权限，从而能够在整个集群中管理节点。

检查访问权限：

配置 RBAC 后，可通过 kubectl auth can-i 命令验证权限，确保角色具备所需的操作权限。
示例：

验证 “john” 是否有权限在 “webapp” 命名空间中列出 pods

 $ kubectl auth can-i list pods --as=system:serviceaccount:web:john -n web
yes

2.执行list pods验证

$ kubectl exec -it -n web nginx -- bash
$ curl -k -s -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc/api/v1/namespaces/web/pods|jq  '.items[].metadata.name'
"my-pod"
"nginx"
"redis-77598f9f86-g4dqg"
"redis-77598f9f86-hpmsh"
"service-python-7f7c9d4fc4-jhp4d"
"webserver-5f9579b5b5-4vj77"
"webserver-5f9579b5b5-qw2m4"

外部用户

1.创建user
在 Kubernetes 中，User 和 ServiceAccount 是独立的概念。一个 User 通常由外部身份管理系统（如 LDAP、OIDC）认证，而 ServiceAccount 是 Kubernetes 内置的一种资源，用于为应用程序或 Pod 提供身份。它们没有直接的关联机制，但可以通过为 User 和 ServiceAccount 配置相同的 RoleBinding 或 ClusterRoleBinding，让它们具有相同的权限，从而达到“关联”目的。

cat <<EOF |kubectl apply -f -
> apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: shared-access-bindingnamespace: web
subjects:
- kind: Username: john  # External userapiGroup: rbac.authorization.k8s.io
- kind: ServiceAccountname: john     # ServiceAccountnamespace: web
roleRef:kind: Rolename: pod-reader-roleapiGroup: rbac.authorization.k8s.io
> EOF

2.验证权限

$ kubectl auth can-i list pods --as=john -n web
yes

3.执行list pods验证

$ sa_john_token=$(kubectl create token john -n web)
$ echo $sa_john_token
eyJhbGciOiJSUzI1NiIsImtpZCI6ImxMVXQ2cTI1cnJFeWVEa0hpWW9SS2oxemRwUVBPWWY3Y0NPZDEtWXViajAifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNzM3NzA0NzUxLCJpYXQiOjE3Mzc3MDExNTEsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwianRpIjoiZjhjYzY3ZWQtYWQ2Mi00OGQ5LTgyNDQtMjg5NDExYTEwODBiIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJ3ZWIiLCJzZXJ2aWNlYWNjb3VudCI6eyJuYW1lIjoiam9obiIsInVpZCI6IjQxMWU5NzU5LTI0ZDItNDEyMy04MTNmLTEyNTdjYzhmNzE4ZCJ9fSwibmJmIjoxNzM3NzAxMTUxLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6d2ViOmpvaG4ifQ.PZPhGJ9djwI0DaTgHGqoQ0nrov2Cokw1WObL42H-TOcRE9SCAgHaxGgIkjAqgJYja5djmjk-SNneSoPD1jq9PTp2NaXBxCfLMHHCfe2QyN0eB3DiV7SFQ2IWZVBFYa6c8ufNFdm85oOPzmcXZDU-T59xpOR6OqgREWhSAQ4LRyFDC-TAqXf1YncKV2i2rItn1OlgNENdqwD2dBYVM9CZvlCt5za7ZwfYcUve1DD9_rZK0VC1Jnc_I8zf8M7mOrucAiZOLXcaFBfFNMPIWa1t1k2EWbnkt8kLFmDkESJ2S1oMHdbpKPZzspFGAtJDMKMHa9W1T3A92kPz_uSGPkRgVg
$ curl -k -s -H "Authorization: Bearer $sa_john_token" https://172.19.6.5:6443/api/v1/namespaces/web/pods | jq '.items[].metadata.name'
"my-pod"
"nginx"
"redis-77598f9f86-g4dqg"
"redis-77598f9f86-hpmsh"
"service-python-7f7c9d4fc4-jhp4d"
"webserver-5f9579b5b5-4vj77"
"webserver-5f9579b5b5-qw2m4"