Authorization

上面認(rèn)證過程，只是確認(rèn)通信的雙方都確認(rèn)了對(duì)方是可信的，可以相互通信。而鑒權(quán)是確定請(qǐng)求方有哪些資源的權(quán)限。API Server目前支持以下幾種授權(quán)策略（通過API Server的啟動(dòng)參數(shù)“–authorization-mode”設(shè)置）

• AlwaysDeny：表示拒絕所有的請(qǐng)求，一般用于測試
• AlwaysAllow：允許接收所有請(qǐng)求，如果集群不需要授權(quán)流程，則可以采用該策略
• ABAC（Attribute-Based Access Control）：基于屬性的訪問控制，表示使用用戶配置的授權(quán)規(guī)則對(duì)用戶請(qǐng)求進(jìn)行匹配和控制
• Webbook：通過調(diào)用外部REST服務(wù)對(duì)用戶進(jìn)行授權(quán)
• RBAC（Role-Based Access Control）：基于角色的訪問控制，現(xiàn)行默認(rèn)規(guī)則

RBAC授權(quán)模式

RBAC（Role-Based Access Control）基于角色的訪問控制，在Kubernetes 1.5中引入，現(xiàn)行版本成為默認(rèn)標(biāo)準(zhǔn)。相對(duì)其它訪問控制方式，擁有以下優(yōu)勢：

• 對(duì)集群中的資源和非資源均擁有完整的覆蓋
• 整個(gè)RBAC完全由幾個(gè)API對(duì)象完成，同其它API對(duì)象一樣，可以用kubectl或API進(jìn)行操作
• 可以在運(yùn)行時(shí)進(jìn)行調(diào)整，無需重啟API Server

Ⅰ、RBAC的API資源對(duì)象說明

RBAC引入了4個(gè)新的頂級(jí)資源對(duì)象：Role、ClusterRole、RoleBinding、ClusterRoleBinding，4種對(duì)象類型均可以通過kubectl與API操作

需要注意的是Kubenetes并不會(huì)提供用戶管理，那么User、Group、ServiceAccount指定的用戶又是從哪里來的呢？Kubenetes組件（kubectl、kube-proxy）或是其他自定義的用戶在向CA申請(qǐng)證書時(shí)，需要提供一個(gè)證書請(qǐng)求文件

{"CN": "admin","hosts": [],"key": {"algo": "rsa","size": 2048},"names": [{"C": "CN","ST": "HangZhou","L": "XS","O": "system:masters","OU": "System"}] }

API Server會(huì)把客戶端證書的CN字段作為User，把names.O字段作為Group

kubelet使用TLS Bootstaping認(rèn)證時(shí)，API Server可以使用Bootstrap Tokens或者Token authenticationfile驗(yàn)證=token，無論哪一種，Kubenetes都會(huì)為token綁定一個(gè)默認(rèn)的User和Group

Pod使用ServiceAccount認(rèn)證時(shí)，service-account-token中的JWT會(huì)保存User信息

有了用戶信息，再創(chuàng)建一對(duì)角色/角色綁定(集群角色/集群角色綁定)資源對(duì)象，就可以完成權(quán)限綁定了

Role and ClusterRole

在RBAC API中，Role表示一組規(guī)則權(quán)限，權(quán)限只會(huì)增加(累加權(quán)限)，不存在一個(gè)資源一開始就有很多權(quán)限而通過RBAC對(duì)其進(jìn)行減少的操作；Role可以定義在一個(gè)namespace中，如果想要跨namespace則可以創(chuàng)建ClusterRole

kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata:namespace: defaultname: pod-reader rules: - apiGroups: [""] # "" indicates the core API groupresources: ["pods"]verbs: ["get","watch","list"]

ClusterRole具有與Role相同的權(quán)限角色控制能力，不同的是ClusterRole是集群級(jí)別的，ClusterRole可以用于:

• 集群級(jí)別的資源控制(例如node訪問權(quán)限)
• 非資源型endpoints(例如/healthz訪問)
• 所有命名空間資源控制(例如pods )

kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata:# "namespace" omitted since ClusterRoles are not namespacedname: secret-reader rules: - apiGroups: [""]resources: ["secrets"]verbs: ["get","watch","list"]

RoleBinding and ClusterRoleBinding

RoloBinding可以將角色中定義的權(quán)限授予用戶或用戶組，RoleBinding包含一組權(quán)限列表(subjects)，權(quán)限列表中包含有不同形式的待授予權(quán)限資源類型(users, groups, or service accounts)；RoloBinding同樣包含對(duì)被Bind的Role引用；RoleBinding適用于某個(gè)命名空間內(nèi)授權(quán)，而ClusterRoleBinding適用于集群范圍內(nèi)的授權(quán)

將default命名空間的pod-reader Role授予jane用戶，此后jane用戶在default命名空間中將具有podreader的權(quán)限

kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata:name: read-podsnamespace: default subjects: - kind: Username: janeapiGroup: rbac.authorization.k8s.io roleRef:kind: Rolename: pod-readerapiGroup: rbac.authorization.k8s.io

RoleBinding同樣可以引用ClusterRole來對(duì)當(dāng)前namespace內(nèi)用戶、用戶組或ServiceAccount進(jìn)行授權(quán)，這種操作允許集群管理員在整個(gè)集群內(nèi)定義一些通用的ClusterRole，然后在不同的namespace中使用RoleBinding來引用

例如，以下RoleBinding引用了一個(gè)ClusterRole，這個(gè)ClusterRole具有整個(gè)集群內(nèi)對(duì)secrets的訪問權(quán)限；但是其授權(quán)用戶dave只能訪問development空間中的secrets(因?yàn)镽oleBinding定義在development命名空間)

# This role binding allows "dave" to read secrets in the "development" namespace. kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata:name: read-secretsnamespace: development # This only grants permissions within the "development" namespace. subjects: - kind: Username: daveapiGroup: rbac.authorization.k8s.io roleRef:kind: ClusterRolename: secret-readerapiGroup: rbac.authorization.k8s.io

使用ClusterRoleBinding可以對(duì)整個(gè)集群中的所有命名空間資源權(quán)限進(jìn)行授權(quán)；以下ClusterRoleBinding樣例展示了授權(quán)manager組內(nèi)所有用戶在全部命名空間中對(duì)secrets進(jìn)行訪問

# This cluster role binding allows anyone in the " manager" group to read secrets in any namespace. kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata:name: read-secrets-global subjects: - kind: Groupname: managerapiGroup: rbac.authorization.k8s.io roleRef:kind: ClusterRolename: secret-readerapiGroup: rbac.authorization.k8s.io

Resources

Kubernetes集群內(nèi)一些資源一般以其名稱字符串來表示，這些字符串一般會(huì)在API的URL地址中出現(xiàn)；同時(shí)某些資源也會(huì)包含子資源，例如logs資源就屬于pods的子資源，API中URL樣例如下

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

如果要在RBAC授權(quán)模型中控制這些子資源的訪問權(quán)限，可以通過 / 分隔符來實(shí)現(xiàn)，以下是一個(gè)定義pods資資源logs訪問權(quán)限的Role定義樣例

kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata:namespace: defaultname: pod-and-pod-logs-reader rules: - apiGroups: [""]resources: ["pods/log"]verbs: ["get","list"]

to Subjects

RoleBinding和ClusterRoleBinding可以將Role綁定到Subjects；Subjects可以是groups、users或者service accounts

Subjects中Users使用字符串表示，它可以是一個(gè)普通的名字字符串，如“alice”；也可以是email格式的郵箱地址，如“Yuan_sr@163.com”；甚至是一組字符串形式的數(shù)字ID。但是Users的前綴 system: 是系統(tǒng)保留的，集群管理員應(yīng)該確保普通用戶不會(huì)使用這個(gè)前綴格式

Groups書寫格式與Users相同，都為一個(gè)字符串，并且沒有特定的格式要求；同樣 system: 前綴為系統(tǒng)保留

實(shí)踐：創(chuàng)建一個(gè)用戶只能管理dev空間

在集群中的一個(gè)節(jié)點(diǎn)創(chuàng)建一個(gè)普通用戶devuser

useradd devuser passwd devuser

此時(shí)登錄devuser后執(zhí)行kubectl get pod 時(shí)什么也看不到，包括default 命名空間下的，因此需要給devuser創(chuàng)建證書訪問信息–config

在集群中創(chuàng)建一個(gè)命名空間供devuser用戶使用

kubectl create namespace dev

編寫證書生成文件的信息devuser-csr.json

{# 用戶名"CN": "devuser",# 指定只能在kubernetes中哪個(gè)節(jié)點(diǎn)可以登錄該用戶"hosts": [], "key": {"algo": "rsa","size": 2048},"names": [{"C": "CN","ST": "ChengDu","L": "ChengDu",# 組名"O": "k8s", "OU": "System"}] } # 下載證書生成工具 wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 mv cfssl_linux-amd64 /usr/local/bin/cfssl wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 mv cfssljson_linux-amd64 /usr/local/bin/cfssljson wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo# 這里首先進(jìn)入/etc/kubernetes/pki目錄下，目的是使用根證書簽發(fā)devuser的客戶端證書請(qǐng)求、證書私鑰和證書，執(zhí)行后生成devuser.csr和deruser-key.pem和deruser.pem三個(gè)文件 cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /root/devuser-csr.json | cfssljson -bare devuser# 設(shè)置集群參數(shù) export KUBE_APISERVER="https://172.20.0.113:6443" # apiserver的訪問地址# 生成deruser.kubeconfig認(rèn)證文件 kubectl config set-cluster kubernetes \ --certificate-authority=/etc/kubernetes/pki/ca.crt \ --embed-certs=true \ --server=${KUBE_APISERVER} \ --kubeconfig=devuser.kubeconfig # 設(shè)置客戶端認(rèn)證參數(shù)（客戶端認(rèn)證信息）,追加到devuser.kubeconfig文件中 kubectl config set-credentials devuser \ --client-certificate=/etc/kubernetes/pki/devuser.pem \ --client-key=/etc/kubernetes/pki/devuser-key.pem \ --embed-certs=true \ --kubeconfig=devuser.kubeconfig# 設(shè)置上下文參數(shù)（命名空間），追加到devuser.kubeconfig文件中 kubectl config set-context kubernetes \ --cluster=kubernetes \ --user=devuser \ --namespace=dev \ --kubeconfig=devuser.kubeconfig# 將集群中默認(rèn)用戶admin綁定到dev命名空間下，這樣admin就可以在該命名空間下為所欲為了 kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev# 登錄deruser用戶后在/root/下創(chuàng)建.kube文件夾 mkdir .kube # 將面生成的devuser.kubeconfig文件拷貝到devuser用戶的/root/.kube/下,并重命名為config cp -f ./devuser.kubeconfig /home/devuser/.kube/config# 給config文件權(quán)限 chown devuser:devuser /home/devuser/.kube/config# 到這里devuser還不能訪問集群中的信息，需要設(shè)置默認(rèn)上下文，登錄devuser用戶執(zhí)行： kubectl config use-context kubernetes --kubeconfig=config

總結(jié)

以上是生活随笔為你收集整理的Kubernetes安全之鉴权的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。