14. 命令行工具
14.1 kubectl create role
创建 Role 对象，定义在某一名字空间中的权限。例如:
创建名称为 “pod-reader” 的 Role 对象，允许用户对 Pods 执行 get、watch 和 list 操作：
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
创建名称为 “pod-reader” 的 Role 对象并指定 resourceNames：
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod -
创建名为 “foo” 的 Role 对象并指定 apiGroups：
kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
创建名为 “foo” 的 Role 对象并指定子资源权限:
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
创建名为 “my-component-lease-holder” 的 Role 对象，使其具有对特定名称的 资源执行 get/update 的权限：
kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
14.2 kubectl create clusterrole
创建 ClusterRole 对象。例如：
创建名称为 “pod-reader” 的 ClusterRole对象，允许用户对 Pods 对象执行 get、watch和list` 操作：
kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
创建名为 “pod-reader” 的 ClusterRole 对象并指定 resourceNames：
kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
创建名为 “foo” 的 ClusterRole 对象并指定 apiGroups：
kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
创建名为 “foo” 的 ClusterRole 对象并指定子资源:
kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
创建名为 “foo” 的 ClusterRole 对象并指定 nonResourceURL：
kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
创建名为 “monitoring” 的 ClusterRole 对象并指定 aggregationRule：
kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
14.3 kubectl create rolebinding
在特定的名字空间中对 Role 或 ClusterRole 授权。例如：
在名字空间 “acme” 中，将名为 admin 的 ClusterRole 中的权限授予名称 “bob” 的用户:
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
在名字空间 “acme” 中，将名为 view 的 ClusterRole 中的权限授予名字空间 “acme” 中名为 myapp 的服务账号：
kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
在名字空间 “acme” 中，将名为 view 的 ClusterRole 对象中的权限授予名字空间 “myappnamespace” 中名称为 myapp 的服务账号：
kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
14.4 kubectl create clusterrolebinding
在整个集群（所有名字空间）中用 ClusterRole 授权。例如：
在整个集群范围，将名为 cluster-admin 的 ClusterRole 中定义的权限授予名为 “root” 用户：
kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
在整个集群范围内，将名为 system:node-proxier 的 ClusterRole 的权限授予名为 “system:kube-proxy” 的用户：
kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
在整个集群范围内，将名为 view 的 ClusterRole 中定义的权限授予 “acme” 名字空间中 名为 “myapp” 的服务账号：
kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
14.5 kubectl auth reconcile
使用清单文件来创建或者更新 rbac.authorization.k8s.io/v1 API 对象。
尚不存在的对象会被创建，如果对应的名字空间也不存在，必要的话也会被创建。 已经存在的角色会被更新，使之包含输入对象中所给的权限。如果指定了 --remove-extra-permissions，可以删除额外的权限。
已经存在的绑定也会被更新，使之包含输入对象中所给的主体。如果指定了 --remove-extra-permissions，则可以删除多余的主体。
例如:
测试应用 RBAC 对象的清单文件，显示将要进行的更改：
kubectl auth reconcile -f my-rbac-rules.yaml --dry-run
应用 RBAC 对象的清单文件，保留角色中的额外权限和绑定中的其他主体：
kubectl auth reconcile -f my-rbac-rules.yaml
应用 RBAC 对象的清单文件, 删除角色中的额外权限和绑定中的其他主体：
kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
15. 服务账号权限
为特定应用的服务账户授予角色（最佳实践）
这要求应用在其 Pod 规约中指定 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
将角色授予某名字空间中的 “default” 服务账号
如果某应用没有指定 serviceAccountName，那么它将使用 “default” 服务账号。
说明： “default” 服务账号所具有的权限会被授予给名字空间中所有未指定 serviceAccountName 的 Pod。
例如，在名字空间 “my-namespace” 中授予服务账号 “default” 只读权限：
kubectl create rolebinding default-view \ --clusterrole=view \ --serviceaccount=my-namespace:default \ --namespace=my-namespace
许多插件组件 在 kube-system 名字空间以 “default” 服务账号运行。 要允许这些插件组件以超级用户权限运行，需要将集群的 cluster-admin 权限授予 kube-system 名字空间中的 “default” 服务账号。
说明： 启用这一配置意味着在 kube-system 名字空间中包含以超级用户账号来访问 API 的 Secrets。
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（或创建 Pod）的用户对你的集群有完全的访问权限。
kubectl create clusterrolebinding serviceaccounts-cluster-admin \ --clusterrole=cluster-admin \ --group=system:serviceaccounts
16. 宽松的 RBAC 权限
下面的策略允许 所有 服务帐户充当集群管理员。 容器中运行的所有应用程序都会自动收到服务帐户的凭据，可以对 API 执行任何操作， 包括查看 Secrets 和修改权限。这一策略是不被推荐的。
kubectl create clusterrolebinding permissive-binding \ --clusterrole=cluster-admin \ --user=admin \ --user=kubelet \ --group=system:serviceaccounts
17. 示例
容器网络接口（CNI）weavework
controlplane $ cat /opt/weave-kube.yaml apiVersion: v1 kind: List items: - apiVersion: v1 kind: ServiceAccount metadata: name: weave-net annotations: cloud.weave.works/launcher-info: |- { "original-request": { "url": "/k8s/v1.10/net.yaml?k8s-version=v1.16.0", "date": "Mon Oct 28 2019 18:38:09 GMT+0000 (UTC)" }, "email-address": "support@weave.works" } labels: name: weave-net namespace: kube-system - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: weave-net annotations: cloud.weave.works/launcher-info: |- { "original-request": { "url": "/k8s/v1.10/net.yaml?k8s-version=v1.16.0", "date": "Mon Oct 28 2019 18:38:09 GMT+0000 (UTC)" }, "email-address": "support@weave.works" } labels: name: weave-net rules: - apiGroups: - '' resources: - pods - namespaces - nodes verbs: - get - list - watch - apiGroups: - networking.k8s.io resources: - networkpolicies verbs: - get - list - watch - apiGroups: - '' resources: - nodes/status verbs: - patch - update - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: weave-net annotations: cloud.weave.works/launcher-info: |- { "original-request": { "url": "/k8s/v1.10/net.yaml?k8s-version=v1.16.0", "date": "Mon Oct 28 2019 18:38:09 GMT+0000 (UTC)" }, "email-address": "support@weave.works" } labels: name: weave-net roleRef: kind: ClusterRole name: weave-net apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: weave-net namespace: kube-system - apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: weave-net annotations: cloud.weave.works/launcher-info: |- { "original-request": { "url": "/k8s/v1.10/net.yaml?k8s-version=v1.16.0", "date": "Mon Oct 28 2019 18:38:09 GMT+0000 (UTC)" }, "email-address": "support@weave.works" } labels: name: weave-net namespace: kube-system rules: - apiGroups: - '' resourceNames: - weave-net resources: - configmaps verbs: - get - update - apiGroups: - '' resources: - configmaps verbs: - create - apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: weave-net annotations: cloud.weave.works/launcher-info: |- { "original-request": { "url": "/k8s/v1.10/net.yaml?k8s-version=v1.16.0", "date": "Mon Oct 28 2019 18:38:09 GMT+0000 (UTC)" }, "email-address": "support@weave.works" } labels: name: weave-net namespace: kube-system roleRef: kind: Role name: weave-net apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: weave-net namespace: kube-system - apiVersion: apps/v1 kind: DaemonSet metadata: name: weave-net annotations: cloud.weave.works/launcher-info: |- { "original-request": { "url": "/k8s/v1.10/net.yaml?k8s-version=v1.16.0", "date": "Mon Oct 28 2019 18:38:09 GMT+0000 (UTC)" }, "email-address": "support@weave.works" } labels: name: weave-net namespace: kube-system spec: minReadySeconds: 5 selector: matchLabels: name: weave-net template: metadata: labels: name: weave-net spec: containers: - name: weave command: - /home/weave/launch.sh env: - name: IPALLOC_RANGE value: 10.32.0.0/24 - name: HOSTNAME valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName image: 'docker.io/weaveworks/weave-kube:2.6.0' readinessProbe: httpGet: host: 127.0.0.1 path: /status port: 6784 resources: requests: cpu: 10m securityContext: privileged: true volumeMounts: - name: weavedb mountPath: /weavedb - name: cni-bin mountPath: /host/opt - name: cni-bin2 mountPath: /host/home - name: cni-conf mountPath: /host/etc - name: dbus mountPath: /host/var/lib/dbus - name: lib-modules mountPath: /lib/modules - name: xtables-lock mountPath: /run/xtables.lock - name: weave-npc env: - name: HOSTNAME valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName image: 'docker.io/weaveworks/weave-npc:2.6.0' resources: requests: cpu: 10m securityContext: privileged: true volumeMounts: - name: xtables-lock mountPath: /run/xtables.lock hostNetwork: true hostPID: true restartPolicy: Always securityContext: seLinuxOptions: {} serviceAccountName: weave-net tolerations: - effect: NoSchedule operator: Exists volumes: - name: weavedb hostPath: path: /var/lib/weave - name: cni-bin hostPath: path: /opt - name: cni-bin2 hostPath: path: /home - name: cni-conf hostPath: path: /etc - name: dbus hostPath: path: /var/lib/dbus - name: lib-modules hostPath: path: /lib/modules - name: xtables-lock hostPath: path: /run/xtables.lock type: FileOrCreate updateStrategy: type: RollingUpdate
参考：
kubernetes Using RBAC Authorization
Extend Kubernetes with Custom Resource Definitions and RBAC for ServiceAccounts
Demystifying RBAC in Kubernetes
