phprbacdemo技巧_Kubernetes 必须掌握技能之 RBAC

RBAC 从 Kubernetes v1.6 处于beta版本，从 v1.8 开始，RBAC已作为 稳定的功能。
启用 RBAC，请利用 --authorization-mode=RBAC 启动 API Server。
[1]

本节将先容RBAC API所定义的四种顶级类型。
用户可以像利用其他Kubernetes API资源一样 （例如通过kubectl、API调用等）与这些资源进行交互。
例如，命令 kubectl create -f (resource).yml 可以被用于以下所有的例子，当然，读者在考试测验前可能须要先阅读以下干系章节的内容。
[1]

Role（角色）：是一系列权限的凑集，例如一个角色可以包含读取 Pod 的权限和列出 Pod 的权限。
Role 只能用来给某个特定 namespace 中的资源作鉴权。
对 namespace 、集群级资源 和 非资源类的 API（如 /healthz）利用 ClusterRole

ClusterRole：工具可以付与与 Role 工具相同的权限，但由于它们属于集群范围工具，也可以利用它们付与对以下几种资源的访问权限：

下面例子描述了 default namespace 中的一个 Role 工具的定义，用于付与对 pod 的读访问权限

kind: RoleapiVersion: rbac.authorization.k8s.io/v1beta1metadata: namespace: default name: demo-rolerules:- apiGroups: [""] # 空字符串""表明利用 core API group resources: ["pods"] verbs: ["get", "watch", "list", "create", "delete"]

下面例子中 ClusterRole 定义可用于付与用户对某一个 namespace，或者 所有 namespace的 secret（取决于其绑定办法）的读访问权限

kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1beta1metadata: # ClusterRole 是集群范围工具，没有 "namespace" 区分 name: demo-clusterrolerules:- apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list", "create", "delete"]ClusterRoleBinding 与 RoleBinding

RoleBinding：把 Role 或 ClusterRole 中定义的各种权限映射到 User，Service Account 或者 Group，从而让这些用户继续角色在 namespace 中的权限。

ClusterRoleBinding：让用户继续 ClusterRole 在全体集群中的权限。

RoleBinding 可以引用在同一命名空间内定义的Role工具。

# 以下角色绑定定义将许可用户 "jane" 从 "default" 命名空间中读取podkind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1beta1metadata: name: read-pods namespace: defaultsubjects:- kind: User name: jane apiGroup: rbac.authorization.k8s.ioroleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

RoleBinding 工具也可以引用一个 ClusterRole 工具用于在 RoleBinding 所在的命名空间内付与用户对所引用的ClusterRole 中定义的命名空间资源的访问权限。
这一点许可管理员在全体集群范围内首先定义一组通用的角色，然后再在不同的命名空间中复用这些角色。

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

# 以下角色绑定许可用户"dave"读取"development"命名空间中的secret。
kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1beta1metadata: name: read-secrets namespace: development # 这里表明仅授权读取"development"命名空间中的资源。
subjects:- kind: User name: dave apiGroup: rbac.authorization.k8s.ioroleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io

末了，可以利用 ClusterRoleBinding 在集群级别和所有命名空间中付与权限。
下面示例中所定义的 ClusterRoleBinding 许可在用户组 ”manager” 中的任何用户都可以读取集群中任何命名空间中的 secret 。

# 以下`ClusterRoleBinding`工具许可在用户组"manager"中的任何用户都可以读取集群中任何命名空间中的secret。
kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1beta1metadata: name: read-secrets-globalsubjects:- kind: Group name: manager apiGroup: rbac.authorization.k8s.ioroleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io对资源的引用

大多数资源由代表其名字的字符串表示，例如 ”pods”，就像它们涌如今干系API endpoint 的URL中一样。
然而，有一些Kubernetes API还 包含了”子资源”，比如 pod 的 logs。
在Kubernetes中，pod logs endpoint的URL格式为：

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

在这种情形下，”pods”是命名空间资源，而”log”是pods的子资源。
为了在RBAC角色中表示出这一点，我们须要利用斜线来划分资源 与子资源。
如果须要角色绑定主体读取pods以及pod log，您须要定义以下角色：

kind: RoleapiVersion: rbac.authorization.k8s.io/v1beta1metadata: namespace: default name: pod-and-pod-logs-readerrules:- apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list"]

通过 resourceNames 列表，角色可以针对不同种类的要求根据资源名引用资源实例。
当指定了 resourceNames 列表时，不同动作 种类的要求的权限，如利用 ”get”、”delete”、”update”以及”patch”等动词的要求，将被限定到资源列表中所包含的资源实例上。
例如，如果须要限定一个角色绑定主体只能 ”get” 或者 ”update” 一个 configmap 时，您可以定义以下角色：

kind: RoleapiVersion: rbac.authorization.k8s.io/v1beta1metadata: namespace: default name: configmap-updaterrules:- apiGroups: [""] resources: ["configmap"] resourceNames: ["my-configmap"] verbs: ["update", "get"]

值得把稳的是，如果设置了 resourceNames，则要求所利用的动词不能是 list、watch、create或者deletecollection。
由于资源名不会涌如今 create、list、watch和deletecollection 等API要求的URL中，以是这些要求动词不会被设置了resourceNames 的规则所许可，由于规则中的 resourceNames 部分不会匹配这些要求。
[1]

例子绑定用户能查看所有 namespaceapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: # 鉴于ClusterRole是集群范围工具，以是这里不须要定 义"namespace"字段 name: view-namespace-clusterrolerules:- apiGroups: - "" resources: - namespaces - namespaces/status verbs: - get - list - watch定义 develop-role 用户对 default 命名空间详细权限apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: name: develop-role namespace: defaultrules:- apiGroups: - "" resources: - endpoints - serviceaccounts - configmaps - persistentvolumeclaims - persistentvolumes - services - replicationcontrollers - replicationcontrollers/scale verbs: - get - list - watch- apiGroups: - "" resources: - pods - pods/log - pods/status - pods/exec verbs: - create - delete - deletecollection - patch - update - get - list - watch- apiGroups: - "" resources: - bindings - events - limitranges - namespaces/status - replicationcontrollers/status - resourcequotas - resourcequotas/status verbs: - get - list - watch- apiGroups: - "" resources: - namespaces verbs: - get - list - watch- apiGroups: - apps resources: - daemonsets - statefulsets verbs: - get - list - watch- apiGroups: - apps resources: - deployments - deployments/scale - replicasets - replicasets/scale verbs: - get - list - watch - update- apiGroups: - autoscaling resources: - horizontalpodautoscalers verbs: - get - list - watch- apiGroups: - batch resources: - cronjobs - jobs verbs: - get - list - watch- apiGroups: - extensions resources: - daemonsets - statefulsets - ingresses - networkpolicies verbs: - get - list - watch- apiGroups: - extensions resources: - deployments - deployments/scale - replicasets - replicasets/scale - replicationcontrollers/scale verbs: - get - list - watch - update- apiGroups: - policy resources: - poddisruptionbudgets verbs: - get - list - watch- apiGroups: - networking.k8s.io resources: - networkpolicies verbs: - get - list - watch默认角色 与 默认角色绑定

API Server 会创建一组默认的 ClusterRole 和 ClusterRoleBinding 工具。
这些默认工具中有许多包含 system: 前缀，表明这些资源由 Kubernetes根本组件”拥有”。
对这些资源的修正可能导致非功能性集群（non-functional cluster）。
一个例子是 system:node ClusterRole 工具。
这个角色定义了 kubelet 的权限。
如果这个角色被修正，可能会导致kubelet 无法正常事情。

所有默认的 ClusterRole 和 ClusterRoleBinding 工具都会被标记为 kubernetes.io/bootstrapping=rbac-defaults。
[1]

通过命令 kubectl get clusterrole 查看到并不是所有都因此 system:前缀，它们是面向用户的角色。
这些角色包含超级用户角色（cluster-admin），即旨在利用 ClusterRoleBinding（cluster-status）在集群范围内授权的角色， 以及那些利用 RoleBinding（admin、edit和view）在特定命名空间中授权的角色。

核心组件角色、其它组件角色 和 掌握器（Controller）角色 这里不在逐一列出。
详细见参考链接中[1]。

所谓 Permissive RBAC 是指授权给所有的 Service Accounts 管理员权限。
不推举的配置

$ kubectl create clusterrolebinding permissive-binding \ --clusterrole=cluster-admin \ --user=admin \ --user=kubelet \ --group=system:serviceaccounts创建用户 shell 脚本

#!/usr/bin/env bash# 把稳修正KUBE_APISERVER为你的API Server的地址KUBE_APISERVER=$1USER=$2USER_SA=system:serviceaccount:default:${USER}Authorization=$3USAGE="USAGE: create-user.sh <api_server> <username> <clusterrole authorization>\nExample: https://192.168.1.2:6443 brand"CSR=`pwd`/user-csr.jsonSSL_PATH="/opt/kubernetes/ssl"USER_SSL_PATH="/opt/kubernetes/create-user"SSL_FILES=(ca-key.pem ca.pem ca-config.json)CERT_FILES=(${USER}.csr $USER-key.pem ${USER}.pem)if [[ $KUBE_APISERVER == "" ]]; then echo -e $USAGE exit 1fiif [[ $USER == "" ]];then echo -e $USAGE exit 1fiif [[ $Authorization == "" ]];then echo -e $USAGE exit 1fi# 创建用户的csr文件function createCSR(){cat>$CSR<<EOF{ "CN": "USER", "hosts": [], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "BeiJing", "L": "BeiJing", "O": "k8s", "OU": "System" } ]}EOF# 更换csr文件中的用户名sed -i "s/USER/$USER_SA/g" $CSR}function ifExist(){if [ ! -f "$SSL_PATH/$1" ]; then echo "$SSL_PATH/$1 not found." exit 1fi}function ifClusterrole(){kubectl get clusterrole ${Authorization} &> /dev/nullif (( $? !=0 ));then echo "${Authorization} clusterrole there is no" exit 1fi}# 判断clusterrole授权是否存在ifClusterrole# 判断证书文件是否存在for f in ${SSL_FILES[@]};do echo "Check if ssl file $f exist..." ifExist $f echo "OK"doneecho "Create CSR file..."createCSRecho "$CSR created"echo "Create user's certificates and keys..."cd $USER_SSL_PATHcfssl gencert -ca=${SSL_PATH}/ca.pem -ca-key=${SSL_PATH}/ca-key.pem -config=${SSL_PATH}/ca-config.json -profile=kubernetes $CSR| cfssljson -bare $USER_SA# 创建 sakubectl create sa ${USER} -n default# 设置集群参数kubectl config set-cluster kubernetes \--certificate-authority=${SSL_PATH}/ca.pem \--embed-certs=true \--server=${KUBE_APISERVER} \--kubeconfig=${USER}.kubeconfig# 设置客户端认证参数kubectl config set-credentials ${USER_SA} \--client-certificate=${USER_SSL_PATH}/${USER_SA}.pem \--client-key=${USER_SSL_PATH}/${USER_SA}-key.pem \--embed-certs=true \--kubeconfig=${USER}.kubeconfig# 设置高下文参数kubectl config set-context kubernetes \--cluster=kubernetes \--user=${USER_SA} \--namespace=development \--kubeconfig=${USER}.kubeconfig# 设置默认高下文kubectl config use-context kubernetes --kubeconfig=${USER}.kubeconfig# 创建 namespace# kubectl create ns $USER# 绑定角色# kubectl create rolebinding ${USER}-admin-binding --clusterrole=admin --user=$USER --namespace=$USER --serviceaccount=$USER:defaultkubectl create clusterrolebinding ${USER}-binding --clusterrole=${Authorization} --user=${USER_SA}# kubectl config get-contextsecho "Congratulations!"echo "Your kubeconfig file is ${USER}.kubeconfig"参考链接[1] https://jimmysong.io/kubernetes-handbook/concepts/rbac.htmlhttps://www.shipengqi.top/kubernetes-learn/auth/rbac.htmlhttps://juejin.im/entry/5b23280ce51d4558cd2acdea