Skip to main content

rbac

认证 授权 准入控制

扩展：创建sa，并授权 sa 的全称是 service account. serviceaccount 是为了方便 Pod 里面 的容器 访问 k8s 集群而设计的。 指定了 serviceaccount 之后，我们把 pod 创建出来了，我们在使用这个 pod时，这个 pod 就有了我们指定的权限去操作 k8s 资源了。 对sa授权

kubectll create clusterrolebinding nfs-provisioner -- clusterrole=cluster-admin --serviceaccount=default:nfs-provisioner

上面我们说了两个角色绑定： (1）用户通过 rolebinding 绑定 role (2）用户通过 clusterrolebinding 绑定 clusterrole 还有一种：rolebinding 绑定 clusterrole

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

rules 中的参数说明：

  1. apiGroups：支持的 API组列表，例如：“apiVersion: batch/v1"等
  2. resources：支持的资源对象列表，例如 pods. deplayments. jobs等
  3. resourceNames:指定 resource 的名称
  4. verbs：对资源对象的操作方法列表。

具有和角色一致的命名空间资源的管理能力，还可用于以下特殊元素的授权 1、集群范围的资源，例如 Node 2、非资源型的路径，例如：/healthz 3、包含全部命名空间的资源，例如 Pods 例如：定义一个集群角色可让用户访问任意 secrets


apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoled
metadata:
  name: secrets-clusterrolee
  rules:
    - apiGroups: [""]
      resources: ["secrets]
      verbs: ["get","watch",”list"]

角色绑定和集群角色绑定用于把一个角色绑定在一个目标上，可以是 User, Group, Service Account，使用 RoleBinding 为某个命名空间授权，使用ClusterRoleBindingl为集群范围内授权。 例如：将在rbac 命名空间中把 pod-read 角色授予用户es


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
  namespacer rbac
subjects:
  - kind: User
    name. es
    apiGroup: rbac.authorization.k8s.io
roleRef:
  - apiGroup: rbac.authorization.k8s.ioe
    kind: ClusterRole
    name: cluster-admin

集群角色绑定的角色只能是集群角色，用于进行集群级别或对所有命名空间都生效的授权 例如：允许manager 组的用户读取所有 namaspace 的 secrets

apiVersion: rbac.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

多数资源可以用其名称的字符串表示，也就是 Endpoint 中的 URL相对路径，例如 pod 中的日志是 GET /api/v1/namaspaces/(namespacel/pods/(podname/log

如果需要在一个 RBAC 对象中体现上下级资源，就需要使用“/”分割资源和下级资源 例如：若想授权让某个主体同时能够读取 Pod 和 Pod log，则可以配置 resources 为一个数组

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 后，使用 get. delete、 update、patch 请求，就会被限制在这个资源实例范围内

例如，下面的声明让一个主体只能对名为 my-configmap 的 ConFigmap 进行 get 和 update操作：

apiVersion: rabc.authorization.k8s.io/v1
kind: Role
metadata:
  namaspace: defaulte
  name: configmap-update
rules:
  - apiGroups: [""]
    resources: ["configmap"]
    resourceNames: ["my-configmap"]
    verbs: ["get", "update"]

（1）允许读取核心 AP1 组的 Pod 资源
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get","list","watch"]
（2） 允许读写 extensions 和apps 两个API 组中的 deployment 交源
rules:
  - apiGroups: ["extensions",”apps"]
    resources: ["deployments"]
    verbs: ["get",“list","watch","create","update',"patch","delete"]

(3） 允许设取 Pod 以及读写job 信息。
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get","list","watch"]
  - apiVersion: ["batch",”extensions"]
    resources: ["jobs"]
    verbs: ["get","list","watch","create","update","patch,"delete"]
    
(4）允许读取一个名为 my-config 的 ConfigMap(必须绑定到一个 RoleBinding 来限制到一个Namespace 下的 ConfigMap)：

rules:
  - apiGroups:
    resources: ["configmap"]
    resourceNames: ["my-configmap"]
    verbs: ["get"]
(5) 读取核心组的 Node 资源(Node 展于集群级的资源，所以必须存在于 ClusterRole 中，井使用 clusterRoleBinding 进行绑定）：

rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get"]
    
(6) 允许对非资源瑞点“/healtht及其所有子路径进行 GET 和 POST 操作 (必须使用
ClusterRole 和 ClusterRole Binding
rules:
  - nonResourceURLs: ["/healthz","/heal"]
	  verbs: ["get","post"]
(3) kube-system 命名空间中默认 Service Account
subjects:
  - kind: ServiceAccount
    name: default
    namespace: kube-system
(4) qa 命名空向中的所有 Service Account:
subjects:
  - kind: Group
    name: system:serviceaccounts:qa
    apiGroup: rbac.authorization.k8s.io
(5) 所有 Service Account
subjects:
  - kind: Group
    name: system:serviceaccounts
    apiGroup: rbac.authorization.k8s.io
    
(6) 所有认证用户
subjects:
  - kind: Group
    name: system:authenticated
    apiGroup: rbac.authorization.k8s.io
（7)所有未认证用户
subjects:
  - kind: Group
    name: system:unauthenticated
    apiGroup: rbac.authorization.k8s.io
(8) 全部用户
subjects:
  - kind: Group
    name: system:authenticated
    apiGroup: rbac.authorization.k8s.io
  - kind: Group
    name: system:unauthenticated
    apiGroup: rbac.authorization.k8s.io

对 Service Account 的授权管理 Service Account 也是一种账号，是给运行在 Pod 里的进程提供了必要的身份证明。需要在 Pod定义中指明引用的 Service Account，这样就可以对 Pod 的进行購权操作。例如：pod内可荻取rbac 命名空间的所有 Pod 资源，pod-reader-sc 的 Service Account 是绑定了名为 pod-read的Role

apiVersion: v1
kind: Pod
metadata:
  name. nginx
  namespace: rbac
spec:
  serviceAccountName: pod-reader-sc
  containers:
    - name: nginx
      image: nginx

默认的 RBAC 第路为控制平台组件、节点和控制器授予有限范国的权限，但是除kube-system 外的 Service Account 是没有任何权限的。 (1）为一个成用专屈的 Service Account 斌权- 此成用需要在 Pbd 的spec 中指定一个 serviceAccountName, 用于 APl. Application Manifest, kubectl create serviceaccount 等创建 Service Account 的命令。

例如为 my-namespace 中的my-sa Service Account 授予只读权限 kubectl create rolebinding my-sa-view Pcluusterrole=view --serviceaccount=my- namespace:my-sa --namespace=my-namespace (2） 为一个命名空间中名为 default 的 Service Account 授权 如果一个成用没有指定 serviceAccountName，则会使用名为 default 的 Service Account.注意，赋子 Service Account “default”的权限会让所有没有指定 serviceAccountName 的 Pod都具有这些权限 例如，在my-namespace 命名空间中为 Service Account "default”授予只读权限： kubectl create rolebinding default-view -clusterrole=view--serviceaccount=my- namespace:default -namespace=my-namespace

(1) 在命名空间rbac 中为用户 es 授权 admin ClusterRole:
kubectl create rolebinding bob-admin-binding --clusterrole=admin -user=es -
namespace=rbac

(2) 在命名空间 rbac中为名为 myapp 的 Service Account 授子 view ClusterRole:
kubctl create rolebinding myapp-role-binding --clusterrole=view
serviceaccount=acme:myapp .-namespace=rbac-
(3）在全集群范国内为用户 root 授予 cluster-admin ClusterRole: 
kubectl create clusterrolebinding cluster-binding --clusterrole =cluster-admin，
user=root