外贸响应式网站设计,淘宝店铺去哪里买,网站建设销售培训,中文wordpress站点文章目录 概要Kubernetes API了解 Kubernetes 中的 RBACRoles and Role Bindings:ClusterRoles and ClusterRoleBindings检查访问权限#xff1a;外部用户结论 概要
Kubernetes 是容器化应用的强大引擎#xff0c;但仅仅关注部署和扩展远远不够#xff0c;集群的安全同样至… 文章目录 概要Kubernetes API了解 Kubernetes 中的 RBACRoles and Role Bindings:ClusterRoles and ClusterRoleBindings检查访问权限外部用户结论 概要
Kubernetes 是容器化应用的强大引擎但仅仅关注部署和扩展远远不够集群的安全同样至关重要。这时角色权限控制Role-Based Access ControlRBAC就派上了用场。本文将深入了解 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 | readwrite | app1 |
| Emily | read | app2 |
| Michael| read | app2 |在此示例中
John 拥有对 app1 的读写权限但无法访问 app2。 Emily 和 Michael对 app2 仅拥有读取权限但无法访问 app1。 当用户和资源数量较少时这种表格形式可以正常使用但随着规模扩大可能会显现一些局限性。
例如如果将 Michael和 Emily 归为同一团队并授予其对 app1 的读取权限表中将需要新增以下条目
| User | Permission | Resource |
| ------ | ---------- | ---------- |
| John | readwrite | app1 |
| Emily | read | app2 |
| Michael| read | app2 |
| Emily | read | app1 |
| Michael| read | app1 |这种设计难以直接体现 Emily和 Michael因同属一个团队而拥有相同访问权限的关系。 可以通过在表中添加“Team”列来解决此问题但更优的方式是拆分这些关系
定义一个通用的权限容器即角色Role。不直接将权限分配给用户而是将权限包含在反映其在组织中角色的角色中。最后将角色与用户关联起来。
可以通过以下方式进行改进
不再使用单一表格而是将结构拆分为两个表格第一个表格将权限映射到角色。第二个表格将角色与身份关联起来。
| Role | Permission | Resource |
| ------ | ---------- | ---------- |
|admin | readwrite | 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及命名空间级别允许执行的actionverbs。以下是 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 --assystem:serviceaccount:web:john -n web
yes2.执行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.ioEOF2.验证权限
$ kubectl auth can-i list pods --asjohn -n web
yes3.执行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
结论
Kubernetes RBAC 是实现集群访问控制的重要机制。通过合理配置 Role、RoleBinding、ClusterRole 和 ClusterRoleBinding可以有效管理用户权限与系统安全之间的关系。定期测试和验证权限配置有助于保持 Kubernetes 环境的稳定性和安全性。
