K8S-RBAC2

bash 复制代码

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

 name: pod-read-bind

 namespace: rbac

subjects:

- kind: User

 name: es

 apiGroup: rbac.authorization.k8s.io

roleRef:

- kind: Role

 name: pod-read

 apiGroup: rbac.authorizatioin.k8s.io

RoleBinding也可以引用ClusterRole，对属于同一命名空间内的ClusterRole定义的资源主体进行授权，例如：es能获取到集群中所有的资源信息

bash 复制代码

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

 name: es-allresource

 namespace: rbac

subjects:

- kind: User

 name: es

 apiGroup: rbac.authorization.k8s.io

roleRef:

 apiGroup: rbac.authorization.k8s.io

 kind: ClusterRole

 name: cluster-admin

集群角色绑定的角色只能是集群角色，用于进行集群级别或对所有命名空间都生效的授权

例如：允许manager组的用户读取所有namaspace的secrets

bash 复制代码

apiVersion: rabc.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

 name: read-secret-global

subjects:

- kind: Group

 name: manager

 apiGroup: rabc.authorization.k8s.io

ruleRef:

- kind: ClusterRole

 name: secret-read

 apiGroup: rabc.authorization.k8s.io

资源引用方式的基本规则

Kubernetes中资源的引用通常使用其名称的字符串表示，对应于API端点中的URL相对路径。例如Pod日志的端点路径为：GET /api/v1/namespaces/{namespace}/pods/{podname}/log

层级资源的表示方法

当需要在RBAC对象中表示资源层级关系时，使用斜杠/分隔主资源和子资源。例如同时授权访问Pod和Pod日志时，resources字段应配置为数组形式：

yaml 复制代码

resources: ["pods", "pods/log"]

常见资源引用示例

以下是一些典型资源引用方式的示例：

核心资源Pod：pods
Pod的子资源日志：pods/log
命名空间资源：namespaces
Deployment资源：deployments

RBAC配置中的资源声明

在Role或ClusterRole定义中，resources字段应采用以下格式声明多级资源：

yaml 复制代码

rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

特殊资源处理

某些资源可能需要特殊处理：

自定义资源使用全小写复数形式
非资源端点如/healthz需要明确声明
资源组需要同时在apiGroups字段声明

bash 复制代码

apiVersion: rabc.authorization.k8s.io/v1

kind: Role

metadata:

 name: logs-reader

 namespace: default

rules:

- apiGroups: [""]

 resources: ["pods","pods/log"]

 verbs: ["get","list"]

资源名称（ResourceName）的作用

通过ResourceName可以限制操作仅针对特定资源实例，而非整个资源类型。这种方式适用于需要对单个资源进行细粒度权限控制的场景。

配置示例

以下RBAC规则限制主体只能对名为my-configmap的ConfigMap执行get和update操作：

yaml 复制代码

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["get", "update"]

适用场景

当需要限制用户只能访问特定命名资源时
需要防止用户查看或修改其他同名资源时
在共享集群环境中隔离资源访问权限时

注意事项

ResourceName字段仅适用于可被名称引用的资源操作，如get/update/patch/delete。对于create或list操作，该字段不应被设置。

操作限制说明

配置后，主体尝试访问其他ConfigMap将返回403 Forbidden错误。只有明确指定的my-configmap资源允许get和update操作。

bash 复制代码

apiVersion: rabc.authorization.k8s.io/v1

kind: Role

metadata:

 namaspace: default

 name: configmap-update

rules:

- apiGroups: [""]

 resources: ["configmap"]

 resourceNames: ["my-configmap"]

 verbs: ["get","update"]

查看资源信息的命令

使用 kubectl api-resources 命令可以列出 Kubernetes 集群中可用的 API 资源。该命令会显示资源的名称、缩写、API 组、是否属于命名空间资源以及资源的类型等信息。

bash 复制代码

kubectl api-resources

输出示例可能包括：

复制代码

NAME          SHORTNAMES   APIGROUP       NAMESPACED   KIND
pods          po                          true         Pod
services      svc                         true         Service
deployments   deploy       apps           true         Deployment

允许读取核心 API 组的 Pod 资源的角色示例

以下是一个 Kubernetes Role 的示例，允许用户读取核心 API 组中的 Pod 资源：

yaml 复制代码

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

关键字段说明：

apiGroups: [""]：表示核心 API 组（如 Pod、Service 等）。
resources: ["pods"]：指定可以访问的资源类型为 Pod。
verbs: ["get", "list", "watch"]：允许的操作包括获取单个 Pod、列出 Pod 列表以及监控 Pod 变化。

应用角色配置

将上述 YAML 保存为文件（例如 pod-reader-role.yaml），然后使用以下命令创建 Role：

bash 复制代码

kubectl apply -f pod-reader-role.yaml

验证角色权限

创建 RoleBinding 将角色绑定到用户或服务账户后，可以通过以下命令验证权限：

bash 复制代码

kubectl auth can-i get pods --as=<user>
kubectl auth can-i list pods --as=<user>

以下是针对Kubernetes RBAC规则的整理和优化，确保权限配置清晰且符合规范：

允许读写extensions和apps组中的deployment资源

yaml 复制代码

rules:
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

允许读取Pod及读写Job信息

yaml 复制代码

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

关键注意事项

apiGroups字段需明确区分核心组（""）与非核心组（如apps、batch）。
extensions组中的Deployment资源在较新Kubernetes版本中已迁移至apps组，建议同时保留兼容性配置。
实际配置时应移除重复的rules条目，避免冗余。

完整RBAC示例

yaml 复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: custom-role
rules:
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

代码格式规范说明

若需提供代码或公式内容，请严格遵循以下格式要求：

代码块格式

使用三个反引号（```）包裹代码，并标注语言类型。例如：

python 复制代码

def hello_world():  
    print("Hello, World!")

数学公式格式

行内公式用 $ 包裹，独立公式用 $$ 包裹。例如：

行内公式： $E=mc^2$ 显示为 $E=mc\^2$
独立公式： $\\int_{a}\^{b} f(x) , dx$

其他注意事项

避免在非代码内容中使用反引号（```）或 $ 符号。
标题层级从三级（###）开始，禁止使用一级或二级标题。
回答中禁止包含步骤词汇（如"首先""然后"）或引用提示词（如"根据引用"）。

如需进一步说明，请明确具体需求或问题类型。

非资源端点权限配置

为允许对非资源端点 /healthz 及其子路径进行 GET 和 POST 操作，需创建 ClusterRole 和 ClusterRoleBinding。以下为配置示例：

ClusterRole 配置：

yaml 复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: healthz-access
rules:
- nonResourceURLs: ["/healthz", "/healthz/*"]
  verbs: ["get", "post"]

ClusterRoleBinding 配置：

yaml 复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: healthz-access-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: healthz-access
subjects:
- kind: User
  name: k8s-master01
  apiGroup: rbac.authorization.k8s.io

角色绑定示例

用户名绑定示例（alice）：

yaml 复制代码

subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io

组名绑定示例（alice）：

yaml 复制代码

subjects:
- kind: Group
  name: alice
  apiGroup: rbac.authorization.k8s.io

关键说明

nonResourceURLs 用于定义非资源型端点（如 /healthz），需明确路径及子路径（/*）。
ClusterRole 和 ClusterRoleBinding 是集群级别的资源，适用于所有命名空间。
绑定到用户或组时，需指定 apiGroup 为 rbac.authorization.k8s.io。

未认证用户与全部用户的RBAC配置解析

在Kubernetes RBAC配置中，system:unauthenticated和system:authenticated是内置的系统组，用于控制不同用户的访问权限。

未认证用户配置

yaml 复制代码

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

该配置针对所有未通过认证的用户，即未提供有效凭证或匿名访问Kubernetes API的用户。

全部用户配置

yaml 复制代码

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

该配置包含两个组，覆盖所有用户：

system:authenticated：所有通过认证的用户
system:unauthenticated：所有未认证的用户

关键区别

未认证用户仅包含system:unauthenticated组
全部用户包含认证和未认证两个组，覆盖所有可能的访问情况

使用场景

限制匿名访问时仅使用system:unauthenticated
需要对所有流量进行控制时使用两个组的组合

未认证用户与全部用户的RBAC配置解析

在Kubernetes RBAC配置中，system:unauthenticated和system:authenticated是内置的系统组，用于控制不同用户的访问权限。

未认证用户配置

yaml 复制代码

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

该配置针对所有未通过认证的用户，即未提供有效凭证或匿名访问Kubernetes API的用户。

全部用户配置

yaml 复制代码

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

该配置包含两个组，覆盖所有用户：

system:authenticated：所有通过认证的用户
system:unauthenticated：所有未认证的用户

关键区别

未认证用户仅包含system:unauthenticated组
全部用户包含认证和未认证两个组，覆盖所有可能的访问情况

使用场景

限制匿名访问时仅使用system:unauthenticated
需要对所有流量进行控制时使用两

Service Account 授权管理

Service Account 是 Kubernetes 中用于赋予 Pod 内进程身份验证和授权的机制。通过将 Service Account 与 RBAC（Role-Based Access Control）结合，可以实现对 Pod 操作的精细化权限控制。

创建 Service Account

在 Kubernetes 中创建 Service Account 非常简单，可以通过以下命令或 YAML 文件创建：
yaml 复制代码
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader-sa
  namespace: rbac
```
保存为 service-account.yaml 后，执行以下命令创建：
bash 复制代码
```
kubectl apply -f service-account.yaml
```
定义 Role 或 ClusterRole

Role 用于定义在特定命名空间内的权限，而 ClusterRole 则适用于整个集群。以下是一个 Role 的示例，允许读取 Pod 资源：
yaml 复制代码
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: rbac
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
```
保存为 role.yaml 并应用：
bash 复制代码
```
kubectl apply -f role.yaml
```
绑定 Service Account 与 Role

通过 RoleBinding 将 Service Account 与 Role 关联起来，赋予 Service Account 相应的权限：
yaml 复制代码
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: rbac
subjects:
- kind: ServiceAccount
  name: pod-reader-sa
  namespace: rbac
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
保存为 role-binding.yaml 并应用：
bash 复制代码
```
kubectl apply -f role-binding.yaml
```
在 Pod 中引用 Service Account

在 Pod 定义中，通过 serviceAccountName 字段指定使用的 Service Account：
yaml 复制代码
```
apiVersion: v1
kind: Pod
metadata:
  name: pod-with-sa
  namespace: rbac
spec:
  serviceAccountName: pod-reader-sa
  containers:
  - name: my-container
    image: busybox
    command: ["sh", "-c", "sleep 3600"]
```
保存为 pod.yaml 并运行：
bash 复制代码
```
kubectl apply -f pod.yaml
```
验证权限

进入 Pod 内部，验证是否具有读取 Pod 的权限：
bash 复制代码
```
kubectl exec -it pod-with-sa -n rbac -- sh
```
在 Pod 内部执行以下命令测试权限：
bash 复制代码
```
kubectl get pods -n rbac
```
如果配置正确，Pod 将能够列出 rbac 命名空间中的所有 Pod 资源。

注意事项
确保 Service Account、Role 和 RoleBinding 在同一个命名空间中。
如果需要跨命名空间或集群范围的权限，使用 ClusterRole 和 ClusterRoleBinding。
定期审计 Service Account 的权限，避免过度授权。

Service Account 授权管理

Service Account 是 Kubernetes 中用于赋予 Pod 内进程身份验证和授权的机制。通过将 Service Account 与 RBAC（Role-Based Access Control）结合，可以实现对 Pod 操作的精细化权限控制。

创建 Service Account

在 Kubernetes 中创建 Service Account 非常简单，可以通过以下命令或 YAML 文件创建：

yaml 复制代码

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader-sa
  namespace: rbac

保存为 service-account.yaml 后，执行以下命令创建：

bash 复制代码

kubectl apply -f service-account.yaml

定义 Role 或 ClusterRole

Role 用于定义在特定命名空间内的权限，而 ClusterRole 则适用于整个集群。以下是一个 Role 的示例，允许读取 Pod 资源：

yaml 复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: rbac
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

保存为 role.yaml 并应用：

bash 复制代码

kubectl apply -f role.yaml

绑定 Service Account 与 Role

通过 RoleBinding 将 Service Account 与 Role 关联起来，赋予 Service Account 相应的权限：

yaml 复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: rbac
subjects:
- kind: ServiceAccount
  name: pod-reader-sa
  namespace: rbac
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

保存为 role-binding.yaml 并应用：

bash 复制代码

kubectl apply -f role-binding.yaml

在 Pod 中引用 Service Account

在 Pod 定义中，通过 serviceAccountName 字段指定使用的 Service Account：

yaml 复制代码

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-sa
  namespace: rbac
spec:
  serviceAccountName: pod-reader-sa
  containers:
  - name: my-container
    image: busybox
    command: ["sh", "-c", "sleep 3600"]

保存为 pod.yaml 并运行：

bash 复制代码

kubectl apply -f pod.yaml

验证权限

进入 Pod 内部，验证是否具有读取 Pod 的权限：

bash 复制代码

kubectl exec -it pod-with-sa -n rbac -- sh

在 Pod 内部执行以下命令测试权限：

bash 复制代码

kubectl get pods -n rbac

如果配置正确，Pod 将能够列出 rbac 命名空间中的所有 Pod 资源。

注意事项

为Service Account赋权的几种方法

应用专属Service Account赋权

在Pod的spec中指定serviceAccountName，通过以下命令为特定Service Account授权。例如为my-namespace中的my-sa授予只读权限：

shell 复制代码

kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace

默认Service Account授权

未指定serviceAccountName的Pod会使用default Service Account。为my-namespace中的default授予只读权限：

shell 复制代码

kubectl create rolebinding default-view --clusterrole=view --serviceaccount=my-namespace:default --namespace=my-namespace

系统级Add-Ons需要超级用户权限时，可为kube-system命名空间的default Service Account赋予cluster-admin权限：

shell 复制代码

kubectl create clusterrolebinding add-ons-add-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default

命名空间内所有Service Account授权

为my-namespace中的所有Service Account授予角色：

shell 复制代码

kubectl create rolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts:my-namespace --namespace=my-namespace

集群范围内所有Service Account授权

为集群内所有Service Account授予低权限角色：

shell 复制代码

kubectl create clusterrolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts

超级用户权限全局授权

为所有Service Account授予cluster-admin权限：

shell 复制代码

kubectl create clusterrolebinding serviceaccounts-cluster-admin --clusterrole=cluster-admin --group=system:serviceaccounts

为Service Account赋权的几种方法

应用专属Service Account赋权

在Pod的spec中指定serviceAccountName，通过以下命令为特定Service Account授权。例如为my-namespace中的my-sa授予只读权限：

shell 复制代码

kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace

默认Service Account授权

未指定serviceAccountName的Pod会使用default Service Account。为my-namespace中的default授予只读权限：

shell 复制代码

kubectl create rolebinding default-view --clusterrole=view --serviceaccount=my-namespace:default --namespace=my-namespace

系统级Add-Ons需要超级用户权限时，可为kube-system命名空间的default Service Account赋予cluster-admin权限：

shell 复制代码

kubectl create clusterrolebinding add-ons-add-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default

命名空间内所有Service Account授权

为my-namespace中的所有Service Account授予角色：

shell 复制代码

kubectl create rolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts:my-namespace --namespace=my-namespace

集群范围内所有Service Account授权

为集群内所有Service Account授予低权限角色：

shell 复制代码

kubectl create clusterrolebinding serviceaccounts-view --clusterrole=view --group=system:serviceaccounts

超级用户权限全局授权

为所有Service Account授予cluster-admin权限：

shell 复制代码

kubectl create clusterrolebinding serviceaccounts-cluster-admin --clusterrole=cluster-admin --group=system:serviceaccounts

确保 Service Account、Role 和 RoleBinding 在同一个命名空间中。

如果需要跨命名空间或集群范围的权限，使用 ClusterRole 和 ClusterRoleBinding。
定期审计 Service Account 的权限，避免过度授权。
个组的组合
bash 复制代码
```
apiVersion: v1

kind: Pod

metadata:

 name: nginx

 namespace: rbac

spec:

 serviceAccountName: pod-reader-sc

 containers:

 k8s-master01- name: nginx

  image: nginx

  imagePullPolicy: IfNotPresent

  ports:

  k8s-master01- containerPort: 80
```
使用 kubectl 创建 RBAC 授权

为用户或 Service Account 授予角色权限

在命名空间内为用户授权

执行以下命令，将 admin ClusterRole 授予用户 es，限制在命名空间 rbac 内生效：
shell 复制代码
```
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=es --namespace=rbac
```
在命名空间内为 Service Account 授权

为命名空间 rbac 中的 Service Account myapp 授予 view ClusterRole：
shell 复制代码
```
kubectl create rolebinding myapp-role-binding --clusterrole=view --serviceaccount=rbac:myapp --namespace=rbac
```
全集群范围授权

为用户授予集群级权限

将 cluster-admin ClusterRole 授予用户 root，权限范围覆盖整个集群：
shell 复制代码
```
kubectl create clusterrolebinding cluster-binding --clusterrole=cluster-admin --user=root
```
为 Service Account 授予集群级权限

为 Service Account myapp 授予 view ClusterRole，权限范围覆盖整个集群：
shell 复制代码
```
kubectl create clusterrolebinding service-account-binding --clusterrole=view --serviceaccount=myapp
```
通过 YAML 文件配置 RBAC

如需通过声明式方式管理权限，可参考 Kubernetes 官方文档中的 YAML 示例：
Kubernetes RBAC 官方文档

关键说明
rolebinding 用于命名空间内权限绑定，clusterrolebinding 用于集群范围权限绑定。
Service Account 需指定命名空间前缀（如 rbac:myapp），否则默认为当前命名空间。
cluster-admin 是最高权限角色，谨慎授予。

使用 kubectl 创建 RBAC 授权

为用户或 Service Account 授予角色权限

在命名空间内为用户授权

执行以下命令，将 admin ClusterRole 授予用户 es，限制在命名空间 rbac 内生效：

shell 复制代码

kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=es --namespace=rbac

在命名空间内为 Service Account 授权

为命名空间 rbac 中的 Service Account myapp 授予 view ClusterRole：

shell 复制代码

kubectl create rolebinding myapp-role-binding --clusterrole=view --serviceaccount=rbac:myapp --namespace=rbac

全集群范围授权

为用户授予集群级权限

将 cluster-admin ClusterRole 授予用户 root，权限范围覆盖整个集群：

shell 复制代码

kubectl create clusterrolebinding cluster-binding --clusterrole=cluster-admin --user=root

为 Service Account 授予集群级权限

为 Service Account myapp 授予 view ClusterRole，权限范围覆盖整个集群：

shell 复制代码

kubectl create clusterrolebinding service-account-binding --clusterrole=view --serviceaccount=myapp

通过 YAML 文件配置 RBAC

如需通过声明式方式管理权限，可参考 Kubernetes 官方文档中的 YAML 示例：
Kubernetes RBAC 官方文档

关键说明

创建 RoleBinding 绑定 ClusterRole

创建名为 lucky 的命名空间：

bash 复制代码

kubectl create ns lucky

将用户 lucky 通过 RoleBinding 绑定到 cluster-admin ClusterRole，并限制权限仅在 lucky 命名空间内有效：

bash 复制代码

kubectl create rolebinding lucky -n lucky --clusterrole=cluster-admin --user=lucky

切换用户上下文

切换到 lucky 用户的上下文（假设已预先配置 lucky@kubernetes 上下文）：

bash 复制代码

kubectl config use-context lucky@kubernetes

验证权限范围

在 lucky 命名空间内测试权限（应有权限）：

bash 复制代码

kubectl get pods -n lucky
kubectl get sa -n lucky

在默认命名空间或其他命名空间测试权限（应无权限）：

bash 复制代码

kubectl get pods  # 默认命名空间
kubectl get pods -n kube-system  # 系统命名空间

关键说明

- rolebinding 用于命名空间内权限绑定，clusterrolebinding 用于集群范围权限绑定。
- Service Account 需指定命名空间前缀（如 rbac:myapp），否则默认为当前命名空间。
- cluster-admin 是最高权限角色，谨慎
  
  生成用户证书并配置Kubernetes访问权限
  
  生成私钥和证书请求
  shell 复制代码
```
cd /etc/kubernetes/pki/
umask 077; openssl genrsa -out lucky.key 2048
openssl req -new -key lucky.key -out lucky.csr -subj "/CN=lucky"
```
  使用集群CA签发证书
  shell 复制代码
```
openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650
```
  配置kubeconfig用户凭证
  shell 复制代码
```
kubectl config set-credentials lucky --client-certificate=./lucky.crt --client-key=./lucky.key --embed-certs=true
kubectl config set-context lucky@kubernetes --cluster=kubernetes --user=lucky
```
  验证用户权限
  shell 复制代码
```
kubectl config use-context lucky@kubernetes
kubectl get pods  # 预期返回权限错误
```
  恢复管理员上下文
  shell 复制代码
```
kubectl config use-context kubernetes-admin@kubernetes
```
  后续权限配置建议
  
  创建Role/RoleBinding或ClusterRole/ClusterRoleBinding为lucky用户授权：
  yaml 复制代码
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: read-pods
subjects:
- kind: User
  name: lucky
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
  生成用户证书并配置Kubernetes访问权限
  
  生成私钥和证书请求
  shell 复制代码
```
cd /etc/kubernetes/pki/
umask 077; openssl genrsa -out lucky.key 2048
openssl req -new -key lucky.key -out lucky.csr -subj "/CN=lucky"
```
  使用集群CA签发证书
  shell 复制代码
```
openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650
```
  配置kubeconfig用户凭证
  shell 复制代码
```
kubectl config set-credentials lucky --client-certificate=./lucky.crt --client-key=./lucky.key --embed-certs=true
kubectl config set-context lucky@kubernetes --cluster=kubernetes --user=lucky
```
  验证用户权限
  shell 复制代码
```
kubectl config use-context lucky@kubernetes
kubectl get pods  # 预期返回权限错误
```
  恢复管理员上下文
  shell 复制代码
```
kubectl config use-context kubernetes-admin@kubernetes
```
  后续权限配置建议
  
  创建Role/RoleBinding或ClusterRole/ClusterRoleBinding为lucky用户授权：
  yaml 复制代码
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: read-pods
subjects:
- kind: User
  name: lucky
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
  创建 RoleBinding 绑定 ClusterRole
  
  创建名为 lucky 的命名空间：
  bash 复制代码
```
kubectl create ns lucky
```
  将用户 lucky 通过 RoleBinding 绑定到 cluster-admin ClusterRole，并限制权限仅在 lucky 命名空间内有效：
  bash 复制代码
```
kubectl create rolebinding lucky -n lucky --clusterrole=cluster-admin --user=lucky
```
  切换用户上下文
  
  切换到 lucky 用户的上下文（假设已预先配置 lucky@kubernetes 上下文）：
  bash 复制代码
```
kubectl config use-context lucky@kubernetes
```
  验证权限范围
  
  在 lucky 命名空间内测试权限（应有权限）：
  bash 复制代码
```
kubectl get pods -n lucky
kubectl get sa -n lucky
```
  在默认命名空间或其他命名空间测试权限（应无权限）：
  bash 复制代码
```
kubectl get pods  # 默认命名空间
kubectl get pods -n kube-system  # 系统命名空间
```
  关键说明
- RoleBinding 的作用域仅限于指定的命名空间（此处为 lucky），即使绑定的 ClusterRole 具有集群范围权限。
- 用户 lucky 需提前在 Kubernetes 集群的认证系统中存在（如通过 kubeconfig 或 RBAC 配置）。
- 若需跨命名空间权限，需使用 ClusterRoleBinding 或为每个命名空间单独创建 RoleBinding。
- - RoleBinding 的作用域仅限于指定的命名空间（此处为 lucky），即使绑定的 ClusterRole 具有集群范围权限。
  - 用户 lucky 需提前在 Kubernetes 集群的认证系统中存在（如通过 kubeconfig 或 RBAC 配置）。
  - 若需跨命名空间权限，需使用 ClusterRoleBinding 或为每个命名空间单独创建 RoleBinding。
  - 授予。
    
    创建用户并配置权限
    
    执行以下命令创建一个名为lucky的普通用户：
    bash 复制代码
```
useradd lucky
```
    复制kube配置文件
    
    将root用户的kube配置文件复制到lucky用户的家目录：
    bash 复制代码
```
cp -ar /root/.kube/ /home/lucky/
```
    修改文件所有权
    
    确保lucky用户对家目录下的文件有所有权：
    bash 复制代码
```
chown -R lucky.lucky /home/lucky/
```
    设置ACL权限
    
    为lucky用户添加读取kubernetes配置文件的权限：
    bash 复制代码
```
setfacl -m u:lucky:r /etc/kubernetes/admin.conf
```
    切换用户并配置环境
    
    切换到lucky用户并配置环境变量：
    bash 复制代码
```
su - lucky
vim .bashrc
```
    在.bashrc文件中添加以下内容：
    bash 复制代码
```
export KUBECONFIG=/etc/kubernetes/admin.conf
```
    保存后执行：
    bash 复制代码
```
source .bashrc
```
    验证配置
    
    验证kubectl命令是否正常工作：
    bash 复制代码
```
kubectl get pods -n lucky
```
    创建用户并配置权限
    
    执行以下命令创建一个名为lucky的普通用户：
    bash 复制代码
```
useradd lucky
```
    复制kube配置文件
    
    将root用户的kube配置文件复制到lucky用户的家目录：
    bash 复制代码
```
cp -ar /root/.kube/ /home/lucky/
```
    修改文件所有权
    
    确保lucky用户对家目录下的文件有所有权：
    bash 复制代码
```
chown -R lucky.lucky /home/lucky/
```
    设置ACL权限
    
    为lucky用户添加读取kubernetes配置文件的权限：
    bash 复制代码
```
setfacl -m u:lucky:r /etc/kubernetes/admin.conf
```
    切换用户并配置环境
    
    切换到lucky用户并配置环境变量：
    bash 复制代码
```
su - lucky
vim .bashrc
```
    在.bashrc文件中添加以下内容：
    bash 复制代码
```
export KUBECONFIG=/etc/kubernetes/admin.conf
```
    保存后执行：
    bash 复制代码
```
source .bashrc
```
    验证配置
    
    验证kubectl命令是否正常工作：
    bash 复制代码
```
kubectl get pods -n lucky
```

资源引用方式的基本规则

层级资源的表示方法

常见资源引用示例

RBAC配置中的资源声明

特殊资源处理

资源名称（ResourceName）的作用

配置示例

适用场景

注意事项

操作限制说明

查看资源信息的命令

允许读取核心 API 组的 Pod 资源的角色示例

应用角色配置

验证角色权限

允许读写extensions和apps组中的deployment资源

允许读取Pod及读写Job信息

关键注意事项

完整RBAC示例

代码格式规范说明

代码块格式

数学公式格式

其他注意事项

非资源端点权限配置

角色绑定示例

关键说明

未认证用户与全部用户的RBAC配置解析

未认证用户配置

全部用户配置

关键区别

使用场景

未认证用户与全部用户的RBAC配置解析

未认证用户配置

全部用户配置

关键区别

使用场景

Service Account 授权管理

创建 Service Account

定义 Role 或 ClusterRole

绑定 Service Account 与 Role

在 Pod 中引用 Service Account

验证权限

注意事项

Service Account 授权管理

创建 Service Account

定义 Role 或 ClusterRole

绑定 Service Account 与 Role

在 Pod 中引用 Service Account

验证权限

注意事项

为Service Account赋权的几种方法

应用专属Service Account赋权

默认Service Account授权

命名空间内所有Service Account授权

集群范围内所有Service Account授权

超级用户权限全局授权

为Service Account赋权的几种方法

应用专属Service Account赋权

默认Service Account授权

命名空间内所有Service Account授权

集群范围内所有Service Account授权

超级用户权限全局授权

使用 kubectl 创建 RBAC 授权

使用 kubectl 创建 RBAC 授权

创建 RoleBinding 绑定 ClusterRole

切换用户上下文

验证权限范围

关键说明

生成用户证书并配置Kubernetes访问权限

后续权限配置建议

生成用户证书并配置Kubernetes访问权限

后续权限配置建议

创建 RoleBinding 绑定 ClusterRole

切换用户上下文

验证权限范围

关键说明

创建用户并配置权限

复制kube配置文件

修改文件所有权

设置ACL权限