kubernetes集羣的認證、受權、准入控制

1、kubernetes集羣安全架構

用戶使用kubectl、客戶機或經過REST請求訪問API。能夠受權用戶和Kubernetes服務賬戶進行API訪問。當一個請求到達API時，它會經歷幾個階段，以下圖所示:

 

1.訪問K8S集羣的資源須要過三關：認證、鑑權、准入控制；

2.普通用戶若要安全訪問集羣API Server，每每須要證書、Token或者用戶名+密碼；

3.Pod訪問，須要ServiceAccountK8S安全控制框架主要由下面3個階段進行控制，每個階段都支持插件方式，經過API Server配置來啓用插件。

• 1. Authentication
• 2. Authorization
• 3. Admission Contro

2、認證

API Server處理請求的過程當中，認證插件負責鑑定⽤戶⾝份，受權插件⽤於操做權限許可鑑別，⽽準⼊控制則⽤於在資源對象的建立、刪除、更新或鏈接（proxy）操做時實現更精細的許可檢查。Kubernetes使⽤⾝份驗證插件對API請求進⾏⾝份驗證，⽀持的認證⽅式包括客戶端證書、承載令牌（bearer tokens）、⾝份驗證代理（authenticating proxy）或HTTP basic認證等。

下面咱們基於客戶端證書來作認證：

1.將apiserver的根證書（ca.pem，ca-key.pem，ca-config.json）放到同一個目錄下執行如下腳本：

[root@master hejianlai]# cat rbac-user.sh 
cat > hejianlai-csr.json <<EOF
{
  "CN": "hejianlai",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "L": "BeiJing",
      "ST": "BeiJing"
    }
  ]
}
EOF

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes hejianlai-csr.json | cfssljson -bare hejianlai 

kubectl config set-cluster kubernetes \
  --certificate-authority=ca.pem \
  --embed-certs=true \
  --server=https://172.31.182.140:6443 \     #Master ip
  --kubeconfig=hejianlai-kubeconfig
  
kubectl config set-credentials hejianlai \
  --client-key=hejianlai-key.pem \
  --client-certificate=hejianlai.pem \
  --embed-certs=true \
  --kubeconfig=hejianlai-kubeconfig

kubectl config set-context default \
  --cluster=kubernetes \
  --user=hejianlai \
  --kubeconfig=hejianlai-kubeconfig

kubectl config use-context default --kubeconfig=hejianlai-kubeconfig

 3、RBAC受權

官方地址：https://kubernetes.io/docs/reference/access-authn-authz/rbac/

RBAC是⼀種操做受權機制，⽤於界定「誰」（subject）可以或不可以「操做」（verb）哪一個或哪類「對象」（object）。動做的發出者即「主體」，一般以「帳號」爲載體，它既能夠是常規⽤戶（User Account），也能夠是服務帳號（Service Account）。「操做」（verb）⽤於代表要執⾏的具體操做，包括建立、刪除、修改和查看等，對應於kubectl來講，它一般由create、apply、delete、update、patch、edit和get等⼦命令來給出。⽽「客體」則是指操做施加於的⽬標實體，對Kubernetes API來講主要是指各種的資源對象以及⾮資源型URL。

 

Kubernetes 使用 API ​​服務器受權 API 請求。它根據全部策略評估全部請求屬性來決定容許或拒絕請求。 一個API請求的全部部分必須被某些策略容許才能繼續。這意味着默認狀況下拒絕權限。

（儘管 Kubernetes 使用 API ​​服務器，可是依賴於特定種類對象的特定字段的訪問控制和策略由准入控制器處理。）

配置多個受權模塊時，將按順序檢查每一個模塊。 若是任何受權模塊批准或拒絕請求，則當即返回該決定，而且不會與其餘受權模塊協商。 若是全部模塊對請求沒有意見，則拒絕該請求。一個拒絕響應返回 HTTP 狀態代碼 403 。

Kubernetes僅審查如下API請求屬性：

• user - 身份驗證期間提供的user字符串。
• group - 通過身份驗證的用戶所屬的組名列表。
• extra - 由身份驗證層提供的任意字符串鍵到字符串值的映射。
• API - 指示請求是否針對 API 資源。
• Request path - 各類非資源端點的路徑，如/api或/healthz。
• API request verb - API 動詞get，list，create，update，patch，watch，proxy，redirect，delete和deletecollection用於資源請求。要肯定資源API端點的請求動詞，請參閱肯定請求動詞。
• HTTP request verb - HTTP 動詞get，post，put和delete用於非資源請求。
• Resource - 正在訪問的資源的 ID 或名稱（僅限資源請求） - 對於使用get，update，patch和delete動詞的資源請求，您必須提供資源名稱。
• Subresource - 正在訪問的子資源（僅限資源請求）。
• Namespace - 正在訪問的對象的名稱空間（僅適用於命名空間資源請求）。
• API group - 正在訪問的 API 組（僅限資源請求）。空字符串表示核心API組。

一、建立role其權限只有簡單的查看pod，我這裏指定命名空間pci

[root@master rbac]# cat role.yaml 
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: pci
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

 2.建立rolebinding 綁定用戶

[root@master rbac]# cat role-binding.yaml 
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: pci
subjects:
- kind: User
  name: hejianlai # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

 3、准入控制

Kubernetes系統經過三個獨⽴的組件間的相互協做來實現服務帳戶的⾃動化，三個組件具體爲：Service Account準⼊控制器、令牌控制器（token controller）和Service Account帳戶控制器。Service Account控制器負責爲名稱空間管理相應的資源，並確保每一個名稱空間中都存在⼀個名爲「default」的Service Account對象。

[root@master hejianlai]# cat sa.yaml 
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader
  namespace: pci

---

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sa-read-pods
  namespace: pci
subjects:
- kind: ServiceAccount
  name: pod-reader
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

 這時咱們能夠看見在pci這個命名中間下有一個默認的defaul和剛建立的pod-reader

這時咱們驗證下權限是否有效：

上圖咱們能夠看到除了該命名空間下除了pod能夠訪問，其餘的權限都是被拒絕的。

經過查看這個pod-reader生成的token咱們就能夠訪問：

kubectl describe secret pod-reader -n pci

記住這個token要複製到記事本里取消自動換行！！！

而後咱們用這個token去訪問UI時也是隻能看到pci這個命名中間下的。