K8S-RBAC2

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能获取到集群中所有的资源信息

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

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字段应配置为数组形式：

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

常见资源引用示例

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

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

RBAC配置中的资源声明

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

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

特殊资源处理

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

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

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操作：

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

适用场景

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

注意事项

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

操作限制说明

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

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 组、是否属于命名空间资源以及资源的类型等信息。

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 资源：

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：

kubectl apply -f pod-reader-role.yaml

验证角色权限

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

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

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

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

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

允许读取Pod及读写Job信息

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示例

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"]

代码格式规范说明

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

代码块格式

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

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

数学公式格式

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

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

其他注意事项

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

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

非资源端点权限配置

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

ClusterRole 配置：

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

ClusterRoleBinding 配置：

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）：

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

组名绑定示例（alice）：

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是内置的系统组，用于控制不同用户的访问权限。

未认证用户配置

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

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

全部用户配置

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是内置的系统组，用于控制不同用户的访问权限。

未认证用户配置

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

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

全部用户配置

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 文件创建：

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

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

  kubectl apply -f service-account.yaml

  定义 Role 或 ClusterRole

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

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

  保存为role.yaml并应用：

  kubectl apply -f role.yaml

  绑定 Service Account 与 Role

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

  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并应用：

  kubectl apply -f role-binding.yaml

  在 Pod 中引用 Service Account

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

  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并运行：

  kubectl apply -f pod.yaml

  验证权限

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

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

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

  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 文件创建：

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

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

kubectl apply -f service-account.yaml

定义 Role 或 ClusterRole

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

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

保存为role.yaml并应用：

kubectl apply -f role.yaml

绑定 Service Account 与 Role

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

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并应用：

kubectl apply -f role-binding.yaml

在 Pod 中引用 Service Account

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

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并运行：

kubectl apply -f pod.yaml

验证权限

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

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

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

kubectl get pods -n rbac

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

注意事项

• 为Service Account赋权的几种方法

  应用专属Service Account赋权

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

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

  默认Service Account授权

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

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

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

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

  命名空间内所有Service Account授权

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

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

  集群范围内所有Service Account授权

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

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

  超级用户权限全局授权

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

  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授予只读权限：

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

  默认Service Account授权

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

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

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

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

  命名空间内所有Service Account授权

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

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

  集群范围内所有Service Account授权

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

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

  超级用户权限全局授权

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

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

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

  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 授予角色权限

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

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

  在命名空间内为 Service Account 授权
  为命名空间rbac中的 Service Accountmyapp授予viewClusterRole：

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

  全集群范围授权

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

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

  为 Service Account 授予集群级权限
  为 Service Accountmyapp授予viewClusterRole，权限范围覆盖整个集群：

  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 授予角色权限

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

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

在命名空间内为 Service Account 授权
为命名空间rbac中的 Service Accountmyapp授予viewClusterRole：

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

全集群范围授权

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

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

为 Service Account 授予集群级权限
为 Service Accountmyapp授予viewClusterRole，权限范围覆盖整个集群：

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

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

关键说明

创建 RoleBinding 绑定 ClusterRole

创建名为lucky的命名空间：

kubectl create ns lucky

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

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

切换用户上下文

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

kubectl config use-context lucky@kubernetes

验证权限范围

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

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

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

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

关键说明

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

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

    生成私钥和证书请求

    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签发证书

    openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650

    配置kubeconfig用户凭证

    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

    验证用户权限

    kubectl config use-context lucky@kubernetes kubectl get pods # 预期返回权限错误

    恢复管理员上下文

    kubectl config use-context kubernetes-admin@kubernetes

    后续权限配置建议

    创建Role/RoleBinding或ClusterRole/ClusterRoleBinding为lucky用户授权：

    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访问权限

    生成私钥和证书请求

    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签发证书

    openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650

    配置kubeconfig用户凭证

    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

    验证用户权限

    kubectl config use-context lucky@kubernetes kubectl get pods # 预期返回权限错误

    恢复管理员上下文

    kubectl config use-context kubernetes-admin@kubernetes

    后续权限配置建议

    创建Role/RoleBinding或ClusterRole/ClusterRoleBinding为lucky用户授权：

    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的命名空间：

    kubectl create ns lucky

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

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

    切换用户上下文

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

    kubectl config use-context lucky@kubernetes

    验证权限范围

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

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

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

    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的普通用户：

      useradd lucky

      复制kube配置文件

      将root用户的kube配置文件复制到lucky用户的家目录：

      cp -ar /root/.kube/ /home/lucky/

      修改文件所有权

      确保lucky用户对家目录下的文件有所有权：

      chown -R lucky.lucky /home/lucky/

      设置ACL权限

      为lucky用户添加读取kubernetes配置文件的权限：

      setfacl -m u:lucky:r /etc/kubernetes/admin.conf

      切换用户并配置环境

      切换到lucky用户并配置环境变量：

      su - lucky vim .bashrc

      在.bashrc文件中添加以下内容：

      export KUBECONFIG=/etc/kubernetes/admin.conf

      保存后执行：

      source .bashrc

      验证配置

      验证kubectl命令是否正常工作：

      kubectl get pods -n lucky

      ​​​​​​​

      创建用户并配置权限

      执行以下命令创建一个名为lucky的普通用户：

      useradd lucky

      复制kube配置文件

      将root用户的kube配置文件复制到lucky用户的家目录：

      cp -ar /root/.kube/ /home/lucky/

      修改文件所有权

      确保lucky用户对家目录下的文件有所有权：

      chown -R lucky.lucky /home/lucky/

      设置ACL权限

      为lucky用户添加读取kubernetes配置文件的权限：

      setfacl -m u:lucky:r /etc/kubernetes/admin.conf

      切换用户并配置环境

      切换到lucky用户并配置环境变量：

      su - lucky vim .bashrc

      在.bashrc文件中添加以下内容：

      export KUBECONFIG=/etc/kubernetes/admin.conf

      保存后执行：

      source .bashrc

      验证配置

      验证kubectl命令是否正常工作：

      kubectl get pods -n lucky

      ​​​​​​​