api k8s restful 创建pods_【大强哥-k8s从入门到放弃10】RBAC详解

最新推荐文章于 2023-02-03 07:31:26 发布

马晓波

最新推荐文章于 2023-02-03 07:31:26 发布

阅读量230

点赞数

文章标签： api k8s restful 创建pods

本文链接：https://blog.csdn.net/weixin_36339157/article/details/112527693

版权

一、何为RBAC

在Kubernetes中，授权有ABAC（基于属性的访问控制）、RBAC（基于角色的访问控制）、Webhook、Node、AlwaysDeny（一直拒绝）和AlwaysAllow（一直允许）这6种模式RBAC全称基于角色的访问控制。

Service Account为服务提供了一种方便的认证机制，但它不关心授权的问题。可以配合RBAC来为Service Account鉴权

从1.6版起，Kubernetes 默认启用RBAC访问控制策略。

从1.8开始，RBAC已作为稳定的功能。

在RABC API中，通过如下的步骤进行授权：

1）定义角色：在定义角色时会指定此角色对于资源的访问控制的规则；
Role、ClusterRole
2）绑定角色：将主体与角色进行绑定，对用户进行访问授权。
RoleBinding或ClusterRoleBinding

RBAC使用"http://rbac.authorization.k8s.io" API Group实现授权决策，允许管理员通过Kubernetes API动态配置策略。

启用RBAC

要启用RBAC，使用--authorization-mode=RBAC启动API Server。

二、Role与ClusterRole

1、角色和集群角色定义

一个角色包含了一套表示一组权限的规则。权限以纯粹的累加形式累积（没有"否定"的规则）。

Role

角色可以由命名空间内的Role对象定义
一个Role对象只能用于授予对某一单一命名空间中资源的访问权限

ClusterRole

整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现。

Role示例

描述"default"命名空间中的一个Role对象的定义，用于授予对pod的读访问权限：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 namespace: default
 name: pod-reader
rules:
- apiGroups: [""] 　　　　　　# 空字符串""表明使用core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole示例

ClusterRole定义可用于授予用户对某一特定命名空间，或者所有命名空间中的secret（取决于其绑定方式）的读访问权限：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:   # ClusterRole是集群范围对象，所以这里不需要定义"namespace"字段
 name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

2、role对资源的引用

大多数资源由代表其名字的字符串表示，如 "pods"，就像它们出现在相关API endpoint的URL中一样。然而，有一些Kubernetes API还包含了 "子资源"

比如pod的logs:

pod logs endpoint的URL格式为：

GET /api/v1/namespaces/{namespace}/pods/{name}/log

这种情况下，"pods" 是命名空间资源，而 "log" 是pods的子资源。

为了在RBAC角色中表示出这一点，需使用斜线来划分资源与子资源。

例子：

如果需要角色绑定主体读取pods以及pod log，需要定义以下角色：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 namespace: default
 name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]　　　　#表示授予读取pods下log的权限
  verbs: ["get", "list"]

resourceNames

通过 resourceNames 列表，角色可以针对不同种类的请求根据资源名引用资源实例。当指定了resourceNames 列表时，不同动作种类的请求的权限，如使用 "get"、"delete"、"update" 以及 "patch" 等动词的请求，将被限定到资源列表中所包含的资源实例上。

例子:

如果需要限定一个角色绑定主体只能 "get" 或者 "update" 一个configmap时，可以定义以下角色：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 namespace: default
 name: configmap-updater
rules:
 - apiGroups: [""]
   resources: ["configmap"]
   resourceNames: ["my-configmap"]
   verbs: ["update", "get"]

注意:

如果设置了resourceNames，则请求所使用的动词不能是list、watch、create或者deletecollection。由于资源名不会出现在create、list、watch和deletecollection等API请求的URL中，所以这些请求动词不会被设置了resourceNames 的规则所允许，因为规则中的resourceNames部分不会匹配这些请求。

3、一大波role定义示例

角色定义的例子

在以下示例中，仅截取展示了rules部分的定义。

允许读取core API Group中定义的资源 "pods"：

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

允许读写在 "extensions" 和 "apps" API Group中定义的 "deployments"：

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

允许读取 "pods" 以及读写 "jobs"：

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

允许读取一个名为 "my-config" 的 ConfigMap 实例（需要将其通过RoleBinding绑定从而限制针对某一个命名空间中定义的一个ConfigMap实例的访问）：

rules:
 - apiGroups: [""]
   resources: ["configmaps"]
   resourceNames: ["my-config"]
   verbs: ["get"]

允许读取core API Group中的"nodes"资源（由于Node是集群级别资源，所以此ClusterRole定义需要与一个ClusterRoleBinding绑定才能有效）：

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

允许对非资源endpoint "/healthz" 及其所有子路径的 "GET" 和 "POST" 请求（此ClusterRole定义需要与一个ClusterRoleBinding绑定才能有效）：

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] 　　# 在非资源URL中，'*'代表后缀通配符
  verbs: ["get", "post"]

三、RoleBinding与ClusterRoleBinding

1、角色绑定和集群角色绑定定义

角色绑定作用：

将一个角色中定义的各种权限授予一个或者一组用户。

角色绑定包含:

1. 一组相关主体, 即:subject
     包括:
       用户--User
       用户组--Group
       服务账户--Service Account 
2. 对被授予角色的引用

RoleBinding

在命名空间中可以通过RoleBinding对象授予权限
RoleBinding可以引用在同一命名空间内定义的Role对象

ClusterRoleBinding

集群范围的权限授予则通过ClusterRoleBinding对象完成。

RoleBinding示例

定义的RoleBinding对象在"default"命名空间中将"pod-reader"角色授予用户"jane"。这一授权将允许用户"jane"从"default"命名空间中读取pod。

以下角色绑定定义将允许用户"jane"从"default"命名空间中读取pod。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: read-pods
 namespace: default
subjects:
- kind: User　　　　　　　　　　#赋予用户jane pod-reader角色权限
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: pod-reader　　　　　　#引用上面定义的role
 apiGroup: rbac.authorization.k8s.io

RoleBinding对象也可以引用一个ClusterRole对象

用于在RoleBinding所在的命名空间内授予用户对所引用的ClusterRole中定义的命名空间资源的访问权限。这一点允许管理员在整个集群范围内首先定义一组通用的角色，然后再在不同的命名空间中复用这些角色。

例如，尽管下面示例中的RoleBinding引用的是一个ClusterRole对象，但是用户"dave"（即角色绑定主体）还是只能读取"development" 命名空间中的secret（即RoleBinding所在的命名空间）。

以下角色绑定允许用户 "dave" 读取 "development" 命名空间中的secret。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: read-secrets
 namespace: development 　　　　　　# 这里表明仅授权读取"development"命名空间中的资源。
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: ClusterRole
 name: secret-reader　　　　　　#引用上面定义的clusterRole 名称（clusterRole没有指定命名空间，默认可以应用所有，但是在rolebinding时，指定了命名空间，所以只能读取本命名空间的文件）
 apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding在集群级别和所有命名空间中授予权限

以下 'ClusterRoleBinding' 对象允许在用户组 "manager" 中的任何用户都可以读取集群中任何命名空间中的secret。

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: ClusterRole
 name: secret-reader
 apiGroup: rbac.authorization.k8s.io

2、对角色绑定主体（Subject）的引用

RoleBinding或者ClusterRoleBinding将角色绑定到角色绑定主体（Subject）。角色绑定主体（kind指定）可以是用户组（Group）、用户（User）或者服务账户（Service Accounts）。

用户

由字符串表示。

纯粹的用户名，例如 "alice"
电子邮件风格的名字，如 "bob@example.com"
用字符串表示的数字id。

用户的产生：

由Kubernetes管理员配置认证模块以产生所需格式的用户名。对于用户名，RBAC授权系统不要求任何特定的格式。

注意：

前缀system:是为Kubernetes系统使用而保留的，所以管理员应该确保用户名不会意外地包含这个前缀。

用户组的产生：

Kubernetes中的用户组信息由授权模块提供。用户组与用户一样由字符串表示。Kubernetes对用户组字符串没有格式要求，但前缀system:同样是被系统保留的。

服务账户：

服务账户（serviceAccount）拥有包含 system:serviceaccount:前缀的用户名，并属于拥有system:serviceaccounts:前缀的用户组。

3、一大波角色绑定示例

角色绑定例子

以下示例中，仅截取展示了RoleBinding的subjects字段。

一个名为"alice@example.com"的用户：
subjects:
- kind: User
  name: "alice@example.com"
  apiGroup: rbac.authorization.k8s.io

一个名为"frontend-admins"的用户组：
subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

kube-system命名空间中的默认服务账户：
subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

名为"qa"命名空间中的所有服务账户：
subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

在集群中的所有服务账户：
subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

所有认证过的用户（version 1.5+）：
subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

所有未认证的用户（version 1.5+）：
subjects:
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

所有用户（version 1.5+）：
subjects:
 - kind: Group
   name: system:authenticated
   apiGroup: rbac.authorization.k8s.io
 - kind: Group
     name: system:unauthenticated
     apiGroup: rbac.authorization.k8s.io

四、默认角色与默认角色绑定

默认角色与默认角色绑定

API Server会创建一组默认的ClusterRole和ClusterRoleBinding对象。这些默认对象中有许多包含system:前缀，表明这些资源由Kubernetes基础组件"拥有"。对这些资源的修改可能导致非功能性集群（non-functional cluster）。

比如：system:node ClusterRole对象。这个角色定义了kubelets的权限。如果这个角色被修改，可能会导致kubelets无法正常工作。

所有默认的ClusterRole和ClusterRoleBinding对象都会被标记为http://kubernetes.io/bootstrapping=rbac-defaults。

每次启动时，API Server都会更新默认ClusterRole所缺乏的各种权限，并更新默认ClusterRoleBinding所缺乏的各个角色绑定主体。这种自动更新机制允许集群修复一些意外的修改。由于权限和角色绑定主体在新的Kubernetes释出版本中可能变化，这也能够保证角色和角色绑定始终保持是最新的。

如果需要禁用自动更新，请将默认ClusterRole以及ClusterRoleBinding的http://rbac.authorization.kubernetes.io/autoupdate 设置成为false。请注意，缺乏默认权限和角色绑定主体可能会导致非功能性集群问题。

自Kubernetes 1.6+起，当集群RBAC授权器（RBAC Authorizer）处于开启状态时，可以启用自动更新功能

发现类角色

默认ClusterRole 默认ClusterRoleBinding 描述

system:basic-user system:authenticated and system:unauthenticatedgroups 允许用户只读访问有关自己的基本信息。

system:discovery system:authenticated and system:unauthenticatedgroups 允许只读访问API discovery endpoints, 用于在API级别进行发现和协商。

面向用户的角色

一些默认角色并不包含system:前缀，它们是面向用户的角色。这些角色包含超级用户角色（cluster-admin），即旨在利用ClusterRoleBinding（cluster-status）在集群范围内授权的角色，以及那些使用RoleBinding（admin、edit和view）在特定命名空间中授权的角色。

默认ClusterRole 默认ClusterRoleBinding 描述

cluster-admin system:mastersgroup 超级用户权限，允许对任何资源执行任何操作。在ClusterRoleBinding中使用时，可以完全控制集群和所有命名空间中的所有资源。在RoleBinding中使用时，可以完全控制RoleBinding所在命名空间中的所有资源，包括命名空间自己。

admin None 管理员权限，利用RoleBinding在某一命名空间内部授予。在RoleBinding中使用时，允许针对命名空间内大部分资源的读写访问，包括在命名空间内创建角色与角色绑定的能力。但不允许对资源配额（resource quota）或者命名空间本身的写访问。

edit None 允许对某一个命名空间内大部分对象的读写访问，但不允许查看或者修改角色或者角色绑定。

view None 允许对某一个命名空间内大部分对象的只读访问。不允许查看角色或者角色绑定。由于可扩散性等原因，不允许查看secret资源。

Core Component Roles核心组件角色

默认ClusterRole 默认ClusterRoleBinding 描述

system:kube-scheduler system:kube-scheduler user 允许访问kube-scheduler组件所需要的资源。

system:kube-controller-manager system:kube-controller-manageruser 允许访问kube-controller-manager组件所需要的资源。单个控制循环所需要的权限请参阅控制器（controller）角色.

system:node system:nodesgroup (deprecated in 1.7) 允许对kubelet组件所需要的资源的访问，包括读取所有secret和对所有pod的写访问。自Kubernetes 1.7开始, 相比较于这个角色，更推荐使用Node authorizer 以及NodeRestriction admission plugin，并允许根据调度运行在节点上的pod授予kubelets API访问的权限。自Kubernetes 1.7开始，当启用Node授权模式时，对system:nodes用户组的绑定将不会被自动创建。

system:node-proxier system:kube-proxyuser 允许对kube-proxy组件所需要资源的访问。

其它组件角色

默认ClusterRole 默认ClusterRoleBinding 描述

system:auth-delegator None 允许委托认证和授权检查。通常由附加API Server用于统一认证和授权。

system:heapster None Heapster组件的角色。

system:kube-aggregator None kube-aggregator组件的角色。

system:kube-dns kube-dns service account in the kube-systemnamespace kube-dns组件的角色。

system:node-bootstrapper None 允许对执行Kubelet TLS引导（Kubelet TLS bootstrapping）所需要资源的访问.

system:node-problem-detector None node-problem-detector组件的角色。

system:persistent-volume-provisioner None 允许对大部分动态存储卷创建组件（dynamic volume provisioner）所需要资源的访问。

控制器（Controller）角色

Kubernetes controller manager负责运行核心控制循环。当使用--use-service-account-credentials选项运行controller manager时，每个控制循环都将使用单独的服务账户启动。而每个控制循环都存在对应的角色，前缀名为system:controller:。如果不使用--use-service-account-credentials选项时，controller manager将会使用自己的凭证运行所有控制循环，而这些凭证必须被授予相关的角色。这些角色包括：

system:controller:attachdetach-controller

system:controller:certificate-controller

system:controller:cronjob-controller

system:controller:daemon-set-controller

system:controller:deployment-controller

system:controller:disruption-controller

system:controller:endpoint-controller

system:controller:generic-garbage-collector

system:controller:horizontal-pod-autoscaler

system:controller:job-controller

system:controller:namespace-controller

system:controller:node-controller

system:controller:persistent-volume-binder

system:controller:pod-garbage-collector

system:controller:replicaset-controller

system:controller:replication-controller

system:controller:resourcequota-controller

system:controller:route-controller

system:controller:service-account-controller

system:controller:service-controller

system:controller:statefulset-controller

system:controller:ttl-controller

初始化与预防权限升级

RBAC API会阻止用户通过编辑角色或者角色绑定来升级权限。由于这一点是在API级别实现的，所以在RBAC授权器（RBAC authorizer）未启用的状态下依然可以正常工作。

用户只有在拥有了角色所包含的所有权限的条件下才能创建／更新一个角色，这些操作还必须在角色所处的相同范围内进行（对于ClusterRole来说是集群范围，对于Role来说是在与角色相同的命名空间或者集群范围）。

例如：

如果用户"user-1"没有权限读取集群范围内的secret列表，那么他也不能创建包含这种权限的ClusterRole。为了能够让用户创建／更新角色，需要：

授予用户一个角色以允许他们根据需要创建／更新Role或者ClusterRole对象。
授予用户一个角色包含他们在Role或者ClusterRole中所能够设置的所有权限。如果用户尝试创建或者修改Role或者ClusterRole以设置那些他们未被授权的权限时，这些API请求将被禁止。

用户只有在拥有所引用的角色中包含的所有权限时才可以创建／更新角色绑定（这些操作也必须在角色绑定所处的相同范围内进行）或者用户被明确授权可以在所引用的角色上执行绑定操作。

例如：

如果用户"user-1"没有权限读取集群范围内的secret列表，那么他将不能创建ClusterRole来引用那些授予了此项权限的角色。为了能够让用户创建／更新角色绑定，需要：

授予用户一个角色以允许他们根据需要创建／更新RoleBinding或者ClusterRoleBinding对象。
授予用户绑定某一特定角色所需要的权限：

隐式地，通过授予用户所有所引用的角色中所包含的权限

显式地，通过授予用户在特定Role（或者ClusterRole）对象上执行bind操作的权限

例如，下面例子中的ClusterRole和RoleBinding将允许用户"user-1"授予其它用户"user-1-namespace"命名空间内的admin、edit和view等角色和角色绑定。

apiVersion: http://rbac.authorization.k8s.io/v1beta1

kind: ClusterRole

metadata:

rules:

- apiGroups: ["http://rbac.authorization.k8s.io"]

resources: ["rolebindings"]

verbs: ["create"]

- apiGroups: ["http://rbac.authorization.k8s.io"]

resources: ["clusterroles"]

verbs: ["bind"]

resourceNames: ["admin","edit","view"]

---

apiVersion: http://rbac.authorization.k8s.io/v1beta1

kind: RoleBinding

metadata:

namespace: user-1-namespace

roleRef:

apiGroup: http://rbac.authorization.k8s.io

kind: ClusterRole

subjects:

- apiGroup: http://rbac.authorization.k8s.io

kind: User

当初始化第一个角色和角色绑定时，初始用户需要能够授予他们尚未拥有的权限。初始化初始角色和角色绑定时需要：

使用包含system：masters用户组的凭证，该用户组通过默认绑定绑定到cluster-admin超级用户角色。

如果API Server在运行时启用了非安全端口（--insecure-port），也可以通过这个没有施行认证或者授权的端口发送角色或者角色绑定请求。

一些命令行工具

有两个kubectl命令可以用于在命名空间内或者整个集群内授予角色。

# kubectl create rolebinding

在某一特定命名空间内授予Role或者ClusterRole

示例如下：

在名为"acme"的命名空间中将admin ClusterRole授予用户"bob"：

# kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme

在名为"acme"的命名空间中将view ClusterRole授予服务账户"myapp"：

# kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme

# kubectl create clusterrolebinding

在整个集群中授予ClusterRole，包括所有命名空间。

示例如下：

在整个集群范围内将cluster-admin ClusterRole授予用户"root"：

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

在整个集群范围内将system:node ClusterRole授予用户"kubelet"：

# kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet

在整个集群范围内将view ClusterRole授予命名空间"acme"内的服务账户"myapp"：

# kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp

服务账户（Service Account）权限

默认的RBAC策略将授予控制平面组件（control-plane component）、节点（node）和控制器（controller）一组范围受限的权限，但对于"kube-system"命名空间以外的服务账户，则不授予任何权限（超出授予所有认证用户的发现权限）。

从最安全到最不安全可以排序以下方法：

对某一特定应用程序的服务账户授予角色（最佳实践）
要求应用程序在其pod规范（pod spec）中指定serviceAccountName字段，并且要创建相应服务账户（例如通过API、应用程序清单或者命令kubectl create serviceaccount等）。

例如：

在"my-namespace"命名空间中授予服务账户"my-sa"只读权限：

kubectl create rolebinding my-sa-view

--clusterrole=view

--serviceaccount=my-namespace:my-sa

--namespace=my-namespace

换成yaml文件大概如下

kind: RoleBinding

apiVersion: http://rbac.authorization.k8s.io/v1beta1

metadata:

namespace: my-namespace

subjects:

- kind: ServiceAccount

apiGroup: http://rbac.authorization.k8s.io

roleRef:

kind: ClusterRole

apiGroup: http://rbac.authorization.k8s.io

在某一命名空间中授予"default"服务账号一个角色

如果一个应用程序没有在其pod规范中指定serviceAccountName，它将默认使用"default"服务账号。

注意：授予"default"服务账号的权限将可用于命名空间内任何没有指定serviceAccountName的pod。

例子：

下面的例子将在"my-namespace"命名空间内授予"default"服务账号只读权限：

kubectl create rolebinding default-view

--clusterrole=view

--serviceaccount=my-namespace:default

--namespace=my-namespace

目前，许多加载项（addon）作为"kube-system"命名空间中的"default"服务帐户运行。要允许这些加载项使用超级用户访问权限，请将cluster-admin权限授予"kube-system"命名空间中的"default"服务帐户。注意：启用上述操作意味着"kube-system"命名空间将包含允许超级用户访问API的秘钥。

# kubectl create clusterrolebinding add-on-cluster-admin

--clusterrole=cluster-admin

--serviceaccount=kube-system:default

为命名空间中所有的服务账号授予角色

如果希望命名空间内的所有应用程序都拥有同一个角色，无论它们使用什么服务账户，可以为该命名空间的服务账户用户组授予角色。

例子：

下面的例子将授予"my-namespace"命名空间中的所有服务账户只读权限：

# kubectl create rolebinding serviceaccounts-view

--clusterrole=view

--group=system:serviceaccounts:my-namespace

--namespace=my-namespace

对集群范围内的所有服务账户授予一个受限角色（不鼓励）

如果不想管理每个命名空间的权限，则可以将集群范围角色授予所有服务帐户。

例子：

下面的例子将所有命名空间中的只读权限授予集群中的所有服务账户：

#kubectl create clusterrolebinding serviceaccounts-view

--clusterrole=view

--group=system:serviceaccounts

授予超级用户访问权限给集群范围内的所有服务帐户（强烈不鼓励）

如果根本不关心权限分块，可以对所有服务账户授予超级用户访问权限。

警告：这种做法将允许任何具有读取权限的用户访问secret或者通过创建一个容器的方式来访问超级用户的凭据。

# kubectl create clusterrolebinding serviceaccounts-cluster-admin

--clusterrole=cluster-admin

--group=system:serviceaccounts

并行授权器（authorizer）

同时运行RBAC和ABAC授权器，并包括旧版ABAC策略：

--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.jsonl

RBAC授权器将尝试首先授权请求。如果RBAC授权器拒绝API请求，则ABAC授权器将被运行。这意味着RBAC策略或者ABAC策略所允许的任何请求都是可通过的。

当以日志级别为2或更高（--v = 2）运行时，可以在API Server日志中看到RBAC拒绝请求信息（以RBAC DENY:为前缀）。可以使用该信息来确定哪些角色需要授予哪些用户，用户组或服务帐户。一旦授予服务帐户角色，并且服务器日志中没有RBAC拒绝消息的工作负载正在运行，可以删除ABAC授权器。

五、RBAC实例

实验说明：创建k8s账号与RBAC授权使用

创建账号

1、创建私钥

# (umask 077; openssl genrsa -out wing.key 2048)

用此私钥创建一个csr(证书签名请求)文件

# openssl  req -new -key wing.key -out wing.csr -subj  "/CN=wing"
# openssl x509 -req -in wing.csr -CA  /etc/kubernetes/pki/ca.crt  -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out wing.crt -days 365

2、查看证书内容

# openssl  x509 -in wing.crt  -text -noout 
# kubectl  config  set-credentials wing  --client-certificate=./wing.crt  --client-key=./wing.key  --embed-certs=true
User "wing" set.

3、设置上下文

# kubectl  config  set-context  wing@kubernetes --cluster=kubernetes --user=wing 

查看当前的工作上下文
# kubectl config view

4、切换用户（切换上下文）

# kubectl  config use-context wing@kubernetes

验证是否已经切换到了新的上下文
# kubectl config current-context

测试（还未赋予权限）

# kubectl  get pod
No resources found.
Error from server (Forbidden): pods is forbidden: User "wing" cannot list pods in the namespace "default"

授权

K8S授权请求是http的请求

对象URL格式：

/apis/[GROUP]/[VERSION]/namespace/[NAMESPACE_NAME]/[KIND]/[OBJECT_ID]

k8s授权方式分为：

serviceaccount和自己签证ca证书的账号，及签证ca的用户组（group）上（授权给这个组的权限）

role说明:
1、允许的操作，如get,list等
2、允许操作的对象，如pod,svc等
rolebinding说明:
将哪个用户绑定到哪个role或clusterrole上
clusterrole：(集群角色)
clusterrolebinding:(绑定到集群)
3、如果使用rolebinding绑定到clusterrole上，表示绑定的用户只能用于当前namespace的权限

创建一个角色（role）

切回管理帐号先

# kubectl  config use-context kubernetes-admin@kubernetes
# kubectl  create role  myrole  --verb=get,list,watch --resource=pod,svc

绑定用户wing（上面创建的用户），绑定role为myrole

# kubectl  create  rolebinding myrole-binding  --role=myrole  --user=wing

切换用户

# kubectl  config use-context wing@kubernetes
    Switched to context "wing@kubernetes".

查看权限（只授权了default名称空间pod和svc的get，list，watch权限）

# kubectl  get pod
NAME                READY   STATUS                          RESTARTS    AGE
nginx-pod         0/1       ImagePullBackOff            0               1h

# kubectl  get pod -n kube-system #无权访问kube-system
No resources found.
Error from server (Forbidden): pods is forbidden: User "wing" cannot list pods in the namespace "kube-system"

# kubectl  delete pod nginx-pod #无删除权限
Error from server (Forbidden): pods "nginx-pod" is forbidden: User "wing" cannot delete pods in the namespace "default"

创建clusterrole #可以访问全部的namespace

# kubectl  create clusterrole mycluster-role --verb=get,list,watch  --resource=pod,svc

删除wing账号之前绑定的rolebinding

# kubectl  delete rolebinding myrole-binding

使用clusterrolebinding绑定clusterrole

# kubectl  create clusterrolebinding my-cluster-rolebinding  --clusterrole=mycluster-role  --user=wing

切换账号

# kubectl  config use-context wing@kubernetes

查看权限查看kube-system空间的pod

# kubectl  get pod -n kube-system
NAME                                 READY   STATUS   RESTARTS  AGE
coredns-78fcdf6894-67h9h     1/1     Running  1             11h
coredns-78fcdf6894-lzxmz     1/1     Running  1             11h
etcd-k8s-m                         1/1       Running  2             11h
......

配置一个新账号和配置文件并授权

创建证书

# (umask 077; openssl genrsa -out k8s.key 2048)

用此私钥创建一个csr(证书签名请求)文件(/0是组名)

# openssl  req -new -key k8s.key -out k8s.csr -subj  "/CN=k8s/O=wing"
# openssl x509 -req -in k8s.csr -CA  /etc/kubernetes/pki/ca.crt  -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out k8s.crt -days 365

查看证书内容

# openssl  x509 -in k8s.crt  -text -noout

创建secret

创建一个generic的secre namespace设置为default

# kubectl  create  secret generic k8s  -n default  --from-file=k8s.crt=./k8s.crt  --from-file=k8s.key=./k8s.key

查看

[root@k8s-m ~]# kubectl  get secret |grep k8s
k8s          Opaque                 2     35s

配置生成

# kubectl config set-cluster  kubernetes   --certificate-authority=/etc/kubernetes/pki/ca.crt  --server="https://10.0.0.141:6443"  --embed-certs=true  --kubeconfig=./k8s.config

配置客户端认证

# kubectl config set-credentials k8s --client-certificate=./k8s.crt  --client-key=./k8s.key --embed-certs=true  --kubeconfig=./k8s.config

配置关联

# kubectl  config  set-context  k8s@user --cluster=kubernetes --user=k8s --kubeconfig=./k8s.config

创建role

# kubectl  create role  k8s-role  --verb=get,list,watch --resource=pod,svc

创建rolebinding

# kubectl  create  rolebinding k8s-rolebinding  --role=k8s-role  --user=k8s

替换配置文件

# mv /root/.kube/config   /mnt/
# cp k8s.config  /root/.kube/config

修改config的current-context内容

current-context: ""
改成#
current-context: name: k8s@user

查看

# kubectl  get pod
NAME           READY   STATUS        RESTARTS  AGE
my-statefulset-0     0/1    ContainerCreating  0      8d
nginx-6f858d4d45-6qm6g  0/1    ImagePullBackOff   0      9d

# kubectl  get pod  -n kube-system
No resources found.
Error from server (Forbidden): pods is forbidden: User "k8s" cannot list pods in the namespace "kube-system"

六、关于设置上下文和账户切换

注：本节即上个实验中用到的切换用户操作

使用kubectl通过终端连接到k8s集群之后。可以设置要在哪个命名空间下进行操作。

设置工作上下文（前提得有用户）

# kubectl  config  set-context  wing@kubernetes --cluster=kubernetes --user=wing

查看当前的工作上下文

# kubectl config view
apiVersion: v1
clusters:
- cluster:
  certificate-authority-data: DATA+OMITTED
  server: https://192.168.1.205:6443
  name: kubernetes
contexts:
- context:
  cluster: kubernetes
  user: kubernetes-admin
  name: kubernetes-admin@kubernetes
- context:
  cluster: kubernetes
  user: wing
  name: wing@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
 - name: kubernetes-admin
   user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
- name: wing
  user:
   client-certificate-data: REDACTED
   client-key-data: REDACTED

切换上下文（切换用户）

# kubectl config use-context wing@kubernetes

马晓波

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
api k8s restful 创建pods_【大强哥-k8s从入门到放弃10】RBAC详解

一、何为RBAC在Kubernetes中，授权有ABAC（基于属性的访问控制）、RBAC（基于角色的访问控制）、Webhook、Node、AlwaysDeny（一直拒绝）和AlwaysAllow（一直允许）这6种模式RBAC全称基于角色的访问控制。Service Account为服务提供了一种方便的认证机制，但它不关心授权的问题。可以配合RBAC来为Service Account鉴权从1.6版起，...
复制链接

扫一扫

api k8s restful 创建pods_【大强哥-k8s从入门到放弃10】RBAC详解

一、何为RBAC

二、Role与ClusterRole

1、角色和集群角色定义

2、role对资源的引用

3、一大波role定义示例

三、RoleBinding与ClusterRoleBinding

1、角色绑定和集群角色绑定定义

2、对角色绑定主体（Subject）的引用

3、一大波角色绑定示例

四、默认角色与默认角色绑定

五、RBAC实例

六、关于设置上下文和账户切换

“相关推荐”对你有帮助么？