一、RBAC認證授權(quán)策略

官方中文參考連接：

在K8S中，所有資源對象都是通過API進行操作，他們保存在ETCD里面，而對ETCD的操作，我們需要通過訪問kube-apiserver來實現(xiàn)，ServiceAccount其實就是apiserver的認證過程，而授權(quán)的機制是通過RBAC，基于角色的訪問控制實現(xiàn)。

RBAC中有四個資源對象，分別是Role、ClusterRole、RoleBinding、ClusterRoleBinding

1、Role角色

Role是一組權(quán)限的集合，在名稱空間下定義的角色，只能對名稱空間下進行資源授權(quán)。如果是集群級別的資源，可以使用clusterrole進行授權(quán)。

實例：定義一個Role賦予讀取 default 名稱空間下所有Pod的權(quán)限：

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: rbac-pod
  namespace: default     # 針對default名稱空間下資源進行授權(quán)
rules:
- apiGroups: ['']
  resources: ["pods"]   # 針對那些資源做授權(quán)，這里是Pod資源
  resourceNames: []     # 上面指定Pod資源，這里表示針對那些Pod資源做授權(quán)，空表示名稱空間下所有Pod
  verbs: ["get", "watch", "list"]  # 授予那些權(quán)限

2、ClusterRole集群角色

ClusterRole是集群角色，跨名稱空間，沒有名稱空間的限制

實例：定義一個ClusterRole賦予讀取所有的Server的權(quán)限：

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterrole-svc
rules:
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get", "watch" ,"list"]

3、RoleBinding角色綁定和ClusterRoleBinding集群角色綁定

角色綁定就是將Role角色和一個目錄進行綁定，可以User、Group、Server Account

使用RoleBinding有名稱空間限制，只能綁定同一個名稱空間的角色，使用ClusterRoleBinding沒有名稱空間限制，為集群范圍內(nèi)授權(quán)。

實例：創(chuàng)建RoleBinding綁定 default名稱空間下rbac-pod 角色授予給 qinzt用戶

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: rbac-pod-qinzt
  namespace: default
subjects:
- kind: User
  name: qinzt
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: rbac-pod
  apiGroup: rbac.authorizatioin.k8s.io

RoleBinding也可以綁定ClusterRole，對屬于同個命名空間的ClusterRole定義的資源主體進行授權(quán)，具體如下：

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: rbac-pod-qinzt
  namespace: default
subjects:
- kind: User
  name: qinzt
  apiGroup: rbac.authorization.k8s.io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole	
  name: clusterrole-svc

二、通過API接口授權(quán)訪問K8S資源

多數(shù)資源可以使用名稱的字符串表示，也就是endpoint中的URL相對路徑，比如Pod中的日志是 GET /api/v1/namaspaces/{namespace}/pods/{podname}/log，如果需要在一個RBAC對象中授權(quán)上下級資源，就需要使用 “/” 分割資源和上下級資源。

實例如下：

第一步：創(chuàng)建 test 名稱空間：

kubectl create namespace test

第二步：創(chuàng)建 logs-reader角色 賦予查看Pod權(quán)限

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

kubectl apply -f logs-reader.yaml
kubectl get role -n test

第三步：創(chuàng)建 sa-test 服務(wù)賬戶

kubectl create sa sa-test -n test

第四步：創(chuàng)建sa-test-1 RoleBinding，將服務(wù)賬戶和角色綁定

kubectl create RoleBinding sa-test-1 -n test --role=logs-readr --serviceaccount=test:sa-test

第五步：創(chuàng)建Pod并使用 sa-test服務(wù)賬戶

cat rbac-pod.yaml 
---
apiVersion: v1
kind: Pod
metadata:
  name: rbac-pod-demo
  namespace: test
  labels:
    app: rbac
spec:
  serviceAccount: sa-test
  containers:
  - name: rbac-pod-demo
    image: nginx
    imagePullPolicy: IfNotPresent

第六步：測試權(quán)限

kubectl exec -it rbac-pod-demo -n test -- /bin/bash
cd /var/run/secrets/kubernetes.io/serviceaccount

# 訪問test名稱空間下rbac-pod-demo Pod日志
curl --cacert ./ca.crt  -H "Authorization: Bearer $(cat ./token)" https://kubernetes.default/api/v1/namespaces/test/pods/rbac-pod-demo/log

curl --cacert ./ca.crt  -H "Authorization: Bearer $(cat ./token)" https://kubrnetes.default/api/v1/namespaces/default/pods/web-nginx-785b94bb7-x298h/log

三、案例：常見授權(quán)策略

1、常見的角色授權(quán)策略案例

案例一：允許讀取核心API組的Pod資源

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

案例二：允許讀寫apps API組中的deployment資源

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

案例三：允許讀取Pod以及讀寫job信息

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

案例四：允許讀取名為nginx.conf的ConfigMap

注意：必須綁定到一個RoleBinding來限制到一個Namespace下的ConfigMap

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["nginx.conf"]
  verbs: ["get"]

案例五：允許讀取核心組的Node資源

注意：Node屬于集群級別的資源，必須使用ClusterRole進行授權(quán)，且必須使用ClusterRoleBinding進行綁定

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

案例六：允許對非資源端點 “/healthz” 及所有子路徑進行GET和POST操作

注意：必須使用ClusterRole和ClusterRoleBinding

rules:
- nonResourceURLs: ["/healthz","/healthz/*"]
  verbs: ["get","post"]

2、常見的角色綁定案例

案例一：綁定qinzt用戶

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

案例二：綁定qinzt組

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

案例三：綁定SA，kube-system名稱空間下默認ServiceAccount

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

3、常見的ServiceAccount授權(quán)綁定案例

案例一：創(chuàng)建名為 t1的RoleBinding將view集群角色和my-namespace名稱空間下 的my-sa SA綁定

kubectl create RoleBinding t1 --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace

案例二：創(chuàng)建名為default-view的RoleBinding將view集群角色和my-namespace名稱空間下的defaultSA綁定

注意：創(chuàng)建名稱空間后，都會存在一個默認的SA賬戶，如果該名稱空間下創(chuàng)建的資源沒有指定SA，默認使用default SA。

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

案例三：創(chuàng)建名為sa-view 的RoleBinding將view集群角色和my-namespace名稱空間下system:serviceaccounts群組進行綁定

注意：如果希望在一個名稱空間下的所有serviceaccount都具有一個權(quán)限，則可以針對群組授權(quán)如下：

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

案例四：為集群范圍內(nèi)所有的serviceaccount都授予一個低權(quán)限角色

kubectl create clusterRoleBinding sa-view --clusterrole=view --group=system:serviceaccounts

案例五：為所有serviceaccount賦予一個超級用戶權(quán)限文章來源地址http://www.zghlxwxcb.cn/news/detail-568227.html

kubectl create clusterRoleBinding sa-view --clusterrole=cluster-admin --group=system:serviceaccounts

到了這里，關(guān)于【Kubernetes運維篇】RBAC認證授權(quán)詳解(二)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！