k8s之权限管理、 rbac授权

一、认证、授权、准入控制

kubernetes的安全框架分三层：认证，授权，准入控制

1、认证（authentication）：验证身份，使用证书、用户名密码或者token令牌。认证解决用户是谁的问题。

2、授权（authorization）：绑定权限，授权过程，分配到指定空间中。授权解决用户能做什么的问题。

3、准入控制（admission control）：空间准入控制，可以使用下面哪些资源，调用哪些插件，使用插件前先与etcd去验证，查看etcd是否授权，若是允许，会执行，并将操作记录到etcd中。准入控制则是资源管理方面的作用。

1、认证 authentication ‘你是谁’

认证方式很多，如：

kubeadm部署的集群，kubeconfig 定义用户的文件就是 X509 Client Certificates方式认证

认证方式	说明	内置	使用场景
X509 Client Certificates	基于客户端 TLS 证书认证	是	集群内部组件（如 kubelet）、管理员
Static Token / Bootstrap Token	静态 Token 文件或启动引导 Token	是（部分已弃用）	初始引导节点加入集群
ServiceAccount Tokens	Pod 内应用使用的 JWT Token	是	集群内服务身份认证
OpenID Connect (OIDC)	与外部身份提供商集成（如 Google、GitHub、Keycloak）	是	企业级用户登录
Webhook Token Authentication	将认证请求发送给外部服务验证	是	与企业 IAM 系统集成
Username/Password (HTTP Basic)	用户名密码（已弃用）	是（不推荐）	旧版本兼容

不同 user 类型对应的认证方式

`user配置方式`	认证类型	说明
`client-certificate-data`+`client-key-data`	X509 客户端证书认证	最传统的方式，常用于管理员或集群组件
`token: <bearer-token>`	Bearer Token 认证	可以是 ServiceAccount Token 或静态 Token
`auth-provider: oidc`	OpenID Connect (OIDC)	与外部身份提供商集成，适合企业用户
`exec`字段调用外部命令	Exec 插件认证	动态获取 Token，如 AWS IAM Authenticator、gcloud 等

X509 客户端证书认证（Client Certificates）

原理：客户端提供由集群 CA 签发的证书和私钥，API Server 验证证书有效性。
优点：安全、无需网络依赖。
缺点：证书管理复杂，难以撤销。
适用场景：
- 集群管理员
- kubelet、kube-proxy 等组件通信

OpenID Connect (OIDC)

原理：集成外部身份提供商（IdP），如 Google、GitHub、Okta、Keycloak。
用户登录后获得一个 ID Token（JWT），kubectl 使用该 Token 认证。
支持刷新 Token、单点登录（SSO）。

Exec 插件认证（Dynamic Client Credentials）

原理：kubeconfig 中定义一个命令，运行时动态生成 Token 或证书。
常用于云厂商集成：
- AWS: aws-iam-authenticator
- GCP: gcloud auth print-access-token
- Azure: az account get-access-token

2、授权 authorization ‘能干什么’

Kubernetes 支持多种授权机制，可以通过 API Server 的启动参数 --authorization-mode 来启用。支持多个模块同时启用，API Server 会按顺序检查，只要有一个允许，就通过授权（短路机制）。

RBAC（Role-Based Access Control）
Node Authorization（节点授权）
Webhook Authorization（外部授权）

一般默认的是 Node,RBAC

查看apiserver启用rbac

ps aux | grep apiserver | grep  authorization-mod
--authorization-mode=Node,RBAC

3、准入控制 admission control ‘是否合法’

Admission Control 是一组插件（Admission Plugins），它们在请求通过认证和授权后、持久化到 etcd 之前，对 API 请求进行拦截，进行：

✅ 验证（Validation）：是否符合策略？
✅ 修改（Mutation）：是否需要自动注入字段？

🔐 只有所有准入插件都通过，请求才会被接受。

`插件`	功能
`NamespaceLifecycle`	防止删除`default`、`kube-system`等系统命名空间
`LimitRanger`	强制 Pod 使用资源限制（requests/limits）
`ResourceQuota`	确保命名空间内资源使用不超限
`PodSecurityPolicy`（已弃用）	控制 Pod 安全上下文（如是否允许特权容器）
`PodSecurity`（替代 PSP）	内置 Pod 安全标准（Baseline、Restricted）
`ServiceAccount`	自动为 Pod 注入 ServiceAccount Token
`MutatingAdmissionWebhook`	启用自定义 mutating webhook
`ValidatingAdmissionWebhook`	启用自定义 validating webhook

查看哪些插件是默认启用的：kubeadm 只开启了一个插件

NodeRestriction：Node加入到K8S集群中以最小权限运行

root@node1:/etc/kubernetes# cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep enable-admission-plugins
    - --enable-admission-plugins=NodeRestriction

root@node1:/etc/kubernetes# ps aux | grep kube-apiserver | grep enable-admission-plugins
root      630001  8.2  1.9 1870844 587660 ?      Ssl  Aug21 738:34 kube-apiserver --advertise-address=192.168.1.240 --allow-privileged=true --authorization-mode=Node,RBAC --client-ca-file=/etc/kubernetes/pki/ca.crt --enable-admission-plugins=NodeRestriction --enable-bootstrap-token-auth=true --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key --etcd-servers=https://127.0.0.1:2379 --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key --requestheader-allowed-names=front-proxy-client --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6443 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/etc/kubernetes/pki/sa.pub --service-account-signing-key-file=/etc/kubernetes/pki/sa.key --service-cluster-ip-range=10.96.0.0/12 --tls-cert-file=/etc/kubernetes/pki/apiserver.crt --tls-private-key-file=/etc/kubernetes/pki/apiserver.key

root@node1:/etc/kubernetes# ps aux | grep kube-apiserver | grep -o '\-\-enable-admission-plugins=[^ ]*'
--enable-admission-plugins=NodeRestriction

k8s集群角色超级管理员cluster-admin，拥有所有权限。

kubectl  get clusterrole | grep cluster
cluster-admin                                                          2020-11-21T15:35:31Z

#kubectl describe clusterrole  cluster-admin
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]
             [*]                []              [*]

二、RBAC 基于角色的访问控制

`1、RBAC用于`授权

RBAC使用rbac.authorization.k8s.io API Group 来实现授权决策

允许管理员通过 Kubernetes API 动态配置策略，要启用RBAC，需要在 apiserver 中添加参数--authorization-mode=RBAC，

如果使用的kubeadm安装的集群，1.6 版本以上的都默认开启RBAC，可以通过查看 Master 节点上 apiserver 的静态Pod定义文件：

# cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep RBAC
    - --authorization-mode=Node,RBAC

如果是二进制的方式搭建的集群，添加这个参数过后，记得要重启 apiserver 服务。

2、RBAC API 对象的概念

`1、`Subject（主体）

表示谁要发起 API 请求，可以是：

User Account（用户账号）

- - 外部身份（例如 Keystone、Google 账号、kubeconfig用户）。
  - Kubernetes 本身不管理用户对象，所以用户账号在集群中没有 API 资源表示。

Group（用户组）

- - 一组用户的集合，集群里预定义了一些组，如 system:masters（cluster-admin 组）。

ServiceAccount（服务账号，SA）

- - Kubernetes 内部用户身份，与 namespace 关联。
  - 适合 Pod、控制器等应用在集群内部调用 API。
  - SA 在集群中是 API 资源对象，可以用 kubectl 管理。
  - 生产中最常用，如 Prometheus、Ingress Controller、Operator 等都会使用。

2、Role 与 ClusterRole （定义权限范围）

Role
- 作用域：单个命名空间
- 仅能授予 namespace 内资源的权限（如 Pod、ConfigMap）。
- 创建时必须指定 namespace。
ClusterRole
- 作用域：集群范围
- 能授予所有命名空间的资源权限，也能授予集群级别资源（如 Node、PersistentVolume）的权限。
- 不受 namespace 限制，可以通过 ClusterRoleBinding 绑定到全局，也可以通过 RoleBinding 绑定到单一 namespace。

3、RoleBinding 与 ClusterRoleBinding

RoleBinding
- 将 Role / ClusterRole 绑定到 Subject。
- 权限范围：仅当前 namespace。
- 可以绑定本 namespace 的 Role，也可以绑定 ClusterRole（但仅在本 namespace 生效）。
ClusterRoleBinding
- 将 ClusterRole 绑定到 Subject。
- 权限范围：全集群所有 namespace。
- 必须绑定 ClusterRole，不能绑定普通 Role。

`字段`	作用
`subjects`	定义谁被授权（用户、组、ServiceAccount）
`roleRef`	定义绑定哪个角色（`Role`或`ClusterRole`）
`namespace`（RoleBinding）	指定作用域命名空间
`apiGroup`in subject/roleRef	指定 API 组，通常是

RoleBinding 字段结构

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: example-rolebinding
  namespace: default  # 必须指定命名空间
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: default
  namespace: default
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role        # 可以是 Role 或 ClusterRole
  name: example-role
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding 字段结构

subjects 中定义谁被授权

　　这里定义了User用户，名为admin，Group组，组名system:masters，ServiceAccount服务账号 ingress-controller

roleRef 中定义绑定哪个角色，即绑定哪条规则

　　这里绑定 ClusterRole 集群角色，即名为 cluster-admin的集群角色

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: example-clusterrolebinding
subjects:
- kind: User
  name: admin
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:masters
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: ingress-controller
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

4、Rule（定义在Role 与 ClusterRole 中）

规则是权限的最小单元，定义了：
- verb（操作）：如 get、list、watch、create、update、delete
- resource（资源）：如 pods、configmaps、nodes
- apiGroup（API 组）：如 ""（核心组，pod、svc 等），apps（deployment、statefulset 等）

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - nodes/metrics
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]

`5、resources 资源`

K8s 所有资源对象都是模型化的 API 对象，允许执行 CRUD(Create、Read、Update、Delete) 操作

Pods
ConfigMaps
Deployments
Nodes
Secrets
Namespaces

6、verbs 资源操作

基础资源操作（CRUD）

`verbs`	说明	`示例`
`get`	获取单个资源对象	`kubectl get pod my-pod`
`list`	列出资源的所有实例	`kubectl get pods`
`create`	创建新资源	`kubectl create -f pod.yaml`
`update`	更新资源的完整定义（全量替换）	修改 Pod 的 spec 字段
`patch`	局部更新资源（只修改部分字段）	`kubectl patch pod my-pod -p '{"spec":...}'`
`delete`	删除单个资源	`kubectl delete pod my-pod`
`deletecollection`	删除某一类资源的全部实例	`kubectl delete pods --all`

特殊子资源操作（Subresource Verbs）

对某类资源有权限后，在细化。如对pod有权限，再对pod的权限细化

`verbs`	`资源类型`	说明
`watch`	`pods`,`deployments`等	监听资源变化事件（用于`kubectl get ... --watch`）
`exec`	`pods/exec`	在 Pod 中执行命令（`kubectl exec`）
`attach`	`pods/attach`	附加到运行中的容器（如`kubectl attach`）
`portforward`	`pods/portforward`	启动端口转发（`kubectl port-forward`）
`proxy`	`services/proxy`,`pods/proxy`	通过 API Server 代理访问服务或 Pod
`forwardport`	（较少见）	类似 portforward
`connect`	`services/proxy`,`nodes/proxy`等	用于代理或连接操作

注意：exec、attach、portforward 等操作必须显式授权，否则即使有 get 权限也无法使用！

只读权限（view）

verbs: ["get", "list", "watch"]

编辑权限（edit）

verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

内置 ClusterRole 中的典型 verbs 示例

集群管理员 cluster-admin

rules中的定义全是通配符*，允许所有操作

# kubectl get clusterrole cluster-admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2025-08-21T02:45:29Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "72"
  uid: 815421d2-d40d-49f3-b7ec-9aaf781ddd23
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
- nonResourceURLs:
  - '*'
  verbs:
  - '*'

集群普通角色 clusterrole

# kubectl get clusterrole view -o yaml
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.authorization.k8s.io/aggregate-to-view: "true"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2025-08-21T02:45:29Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
  name: view
  resourceVersion: "320"
  uid: 1118a67a-aa5f-401e-9a37-96fa2bb1b51e
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - persistentvolumeclaims
  - persistentvolumeclaims/status
  - pods
  - replicationcontrollers
  - replicationcontrollers/scale
  - serviceaccounts
  - services
  - services/status
  verbs:
  - get
  - list
  - watch

7、 API Group

K8s 的 API 被划分为多个 API 组（API Groups），每个组管理一类资源。这种设计支持扩展性和版本控制。

简单理解：apiGroups 就像“目录分类”，resources 是这个目录下的“文件名”。

常见的 apiGroups 及其管理的资源

`API 组`	说明	`资源类型`
`""`（空字符串）	核心组（Core Group），这是默认组，不写 group 名称即表示它	`pods`,`services`,`configmaps`,`secrets`,`nodes`,`namespaces`,`persistentvolumes`,`serviceaccounts`
`apps`	应用工作负载相关资源	`deployments`,`daemonsets`,`replicasets`,`statefulsets`,`controllerrevisions`
`batch`	批处理任务	`jobs`,`cronjobs`
`extensions`	⚠️ 已弃用（旧版 NetworkPolicy、Ingress 等）	旧版`deployments`,`ingress`,`networkpolicies`（现在迁移到其他组）
`networking.k8s.io`	网络策略和 Ingress	`ingress`,`ingressclasses`,`networkpolicies`
`rbac.authorization.k8s.io`	RBAC 权限系统自身资源	`roles`,`rolebindings`,`clusterroles`,`clusterrolebindings`
`storage.k8s.io`	存储相关	`storageclasses`,`volumeattachments`,`csidrivers`
`policy`	安全策略（已弃用 PSP，但仍有部分使用）	`podsecuritypolicies`（PSP，v1.25+ 移除）
`autoscaling`	自动扩缩容	`horizontalpodautoscalers`（HPA）
`certificates.k8s.io`	证书申请与签发	`certificatesigningrequests`（CSR）
`apiextensions.k8s.io`	自定义资源定义（CRD）	`customresourcedefinitions`（CRD）
`scheduling.k8s.io`	调度策略	`priorityclasses`
`coordination.k8s.io`	协调机制（如 Lease）	`leases`（用于 kube-controller-manager 等）

特殊的非资源型 Group（Non-resource URLs）

有些路径不是资源，而是直接的 HTTP 路径，比如 /healthz、/version，它们属于“非资源端点”，用特殊方式表示：

- nonResourceURLs: ["/healthz", "/healthz/*", "/version"]
  verbs: ["get"]

通配符支持

`写法`	含义
`[""]`	核心组
`["apps"]`	apps 组
`["*"]`	所有 API 组（慎用！）
`["", "apps", "batch"]`	多个组

3、rbac 结构示意图

RBAC 是 K8s 中用于控制用户和服务账户对集群资源操作权限的核心授权机制。

它通过定义“谁（Subject）”可以在“哪些资源（Resource）”上执行“什么操作（Verb）”来实现精细化的权限管理。

                +-------------------------+
                |        Subject          |
                | (User / Group / SA)     |
                +-----------+-------------+
                            |
                            v
             +--------------+-------------------+
             |                                  |
+------------+-----------+        +-------------+------------+
|   RoleBinding (NS)     |        |  ClusterRoleBinding      |
|  绑定到某个命名空间内     |        |   集群范围绑定             |
+------------+-----------+        +-------------+------------+
             |                                  |
             v                                  v
   +---------+---------+             +----------+----------+
   |        Role       |             |     ClusterRole     |
   | (Namespace 级规则) |             | (Cluster 级规则)     |
   +---------+---------+             +----------+----------+
             |                                  |
             +----------------+-----------------+
                              |
                              v
                     +--------+---------+
                     |   API Request    |
                     | [verb] [resource]|  
                     +------------------+

补充:

API Request：
- 最终就是对 K8s API Server 发起的动作。
- 是否允许，取决于 RBAC 是否匹配上。

4、创建一个 User Account 示例

只能访问 kube-system 这个命名空间

username: zjz
group: cetc

第1步：创建用户凭证

我们前面已经提到过，Kubernetes没有 User Account 的 API 对象，不过要创建一个用户帐号的话也是挺简单的，利用管理员分配给你的一个私钥就可以创建了，参考https://kubernetes.io/docs/reference/access-authn-authz/authentication/，这里我们来使用OpenSSL证书来创建一个 User，当然我们也可以使用更简单的cfssl工具来创建：
给用户 zjz创建一个私钥，命名成：zjz.key：

# openssl genrsa -out zjz.key 2048
Generating RSA private key, 2048 bit long modulus
..............+++
....................................+++
e is 65537 (0x10001)

使用我们刚刚创建的私钥创建一个证书签名请求文件：zjz.csr，要注意需要确保在-subj参数中指定用户名和组(CN表示用户名，O表示组)：

# openssl req -new -key zjz.key -out zjz.csr -subj "/CN=zjz/O=cetc"

然后找到我们的Kubernetes集群的CA，我们使用的是kubeadm安装的集群，CA相关证书位于/etc/kubernetes/pki/目录下面，如果你是二进制方式搭建的，你应该在最开始搭建集群的时候就已经指定好了CA的目录，我们会利用该目录下面的ca.crt和ca.key两个文件来批准上面的证书请求

生成最终的证书文件，我们这里设置证书的有效期为500天：

# openssl x509 -req -in zjz.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out zjz.crt -days 500
Signature ok
subject=/CN=zjz/O=cetc
Getting CA Private Key

现在查看我们当前文件夹下面是否生成了一个证书文件：

ls
zjz.crt      zjz.key      zjz.csr

现在我们可以使用刚刚创建的证书文件和私钥文件在集群中创建新的凭证和上下文(Context):

# kubectl config set-credentials zjz --client-certificate=zjz.crt  --client-key=zjz.key
User "zjz" set.

我们可以看到一个用户zjz创建了，然后为这个用户设置新的 Context:

# kubectl config set-context zjz-context --cluster=kubernetes --namespace=kube-system --user=zjz
Context "zjz-context" created.

到这里，我们的用户zjz就已经创建成功了，现在我们使用当前的这个配置文件来操作kubectl命令的时候，应该会出现错误，因为我们还没有为该用户定义任何操作的权限呢：

kubectl get pods --context=zjz-context
Error from server (Forbidden): pods is forbidden: User "zjz" cannot list resource "pods" in API group "" in the namespace "kube-system"

第2步：创建角色

用户创建完成后，接下来就需要给该用户添加操作权限，我们来定义一个YAML文件，创建一个允许用户操作 Deployment、Pod、ReplicaSets 的角色，如下定义：(zjz-role.yaml)

# cat zjz-role.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: zjz-role
  namespace: kube-system
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["deployments", "replicasets", "pods"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # 也可以使用['*']

其中Pod属于 core 这个 API Group，在YAML中用空字符就可以，而Deployment属于 apps 这个 API Group，ReplicaSets属于extensions这个 API Group(
我怎么知道的？https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/)，
所以 rules 下面的 apiGroups 就综合了这几个资源的 API Group：["", "extensions", "apps"]，其中verbs就是我们上面提到的可以对这些资源对象执行的操作，
我们这里需要所有的操作方法，所以我们也可以使用['*']来代替。

然后创建这个Role：

kubectl create -f zjz-role.yaml
注意这里我们没有使用上面的zjz-context这个上下文，因为没有权限

第3步：创建角色权限绑定

Role 创建完成了，但是很明显现在我们这个 Role 和我们的用户 zjz 还没有任何关系，对吧？这里我就需要创建一个RoleBinding对象，

在 kube-system 这个命名空间下面将上面的 zjz-role 角色和用户 zjz 进行绑定:(zjz-rolebinding.yaml)

# cat zjz-rolebinding.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: zjz-rolebinding
  namespace: kube-system
subjects:
- kind: User
  name: zjz
  apiGroup: ""
roleRef:
  kind: Role
  name: zjz-role
  apiGroup: ""

上面的YAML文件中我们看到了subjects关键字，这里就是我们上面提到的用来尝试操作集群的对象，这里对应上面的 User 帐号 zjz，使用kubectl创建上面的资源对象：

 kubectl create -f zjz-rolebinding.yaml

第4步. 测试

现在我们应该可以上面的haimaxy-context上下文来操作集群了：

# kubectl get pods --context=zjz-context
NAME                             READY   STATUS    RESTARTS   AGE
coredns-66bff467f8-gs592         1/1     Running   0          3h36m
coredns-66bff467f8-vrk4l         1/1     Running   0          3h36m
etcd-master                      1/1     Running   0          3h36m
kube-apiserver-master            1/1     Running   0          3h36m
kube-controller-manager-master   1/1     Running   0          3h36m
kube-flannel-ds-amd64-hcsnq      1/1     Running   0          119m
kube-flannel-ds-amd64-nwlvk      1/1     Running   0          119m
kube-flannel-ds-amd64-pzh5q      1/1     Running   0          119m
kube-proxy-2sbdv                 1/1     Running   0          3h36m
kube-proxy-jj6nh                 1/1     Running   0          174m
kube-proxy-qr625                 1/1     Running   0          175m
kube-scheduler-master            1/1     Running   0          3h36m

我们可以看到我们使用kubectl的使用并没有指定 namespace 了，这是因为我们已经为该用户分配了权限了，如果我们在后面加上一个-n default试看看呢？

$ kubectl --context=zjz-context get pods --namespace=default
Error from server (Forbidden): pods is forbidden: User "haimaxy" cannot list pods in the namespace "default"

https://segmentfault.com/a/1190000021905208 permission-manager 是一个用于 K8s RBAC 和用户管理的web工具。

https://blog.csdn.net/wangshui898/article/details/110817257 K8S基础-鉴权框架与用户权限分配，总结不错

Auto Copied

posted @ 2020-07-06 14:26 凡人半睁眼阅读(3545) 评论(0) 收藏举报

刷新页面返回顶部

海棠未雨，梨花先雪，一半春休

想看山海，早也去，晚也去，一个人也去

k8s之权限管理、 rbac授权

一、认证、授权、准入控制

1、认证 authentication ‘你是谁’

2、授权 authorization ‘能干什么’

3、准入控制 admission control ‘是否合法’

二、RBAC 基于角色的访问控制

`1、RBAC用于`授权

2、RBAC API 对象的概念

`1、`Subject（主体）

2、Role 与 ClusterRole （定义权限范围）

3、RoleBinding 与 ClusterRoleBinding

4、Rule（定义在Role 与 ClusterRole 中）

`5、resources 资源`

6、verbs 资源操作

7、 API Group

3、rbac 结构示意图

4、创建一个 User Account 示例

第1步：创建用户凭证

第2步：创建角色

第3步：创建角色权限绑定

第4步. 测试

公告

海棠未雨，梨花先雪，一半春休

想看山海，早也去，晚也去 ，一个人也去

k8s之权限管理、 rbac授权

一、认证、授权、准入控制

1、认证 authentication ‘你是谁’

2、授权 authorization ‘能干什么’

3、准入控制 admission control ‘是否合法’

二、RBAC 基于角色的访问控制

1、RBAC用于授权

2、RBAC API 对象的概念

1、Subject（主体）

2、Role 与 ClusterRole （定义权限范围 ）

3、RoleBinding 与 ClusterRoleBinding

4、Rule（定义在Role 与 ClusterRole 中）

5、resources 资源

6、verbs 资源操作

7、 API Group

3、rbac 结构示意图

4、创建一个 User Account 示例

第1步：创建用户凭证

第2步：创建角色

第3步：创建角色权限绑定

第4步. 测试

公告

想看山海，早也去，晚也去，一个人也去

`1、RBAC用于`授权

`1、`Subject（主体）

2、Role 与 ClusterRole （定义权限范围）

`5、resources 资源`