K8s 身份認證和權限

Kubernetes 中提供了良好的多租戶認證管理機制，如 RBAC、ServiceAccount 還有各種策略等。

通過該文件可以看到已經配置了 RBAC 訪問控制

/usr/lib/systemd/system/kube-apiserver.service

認證

所有 Kubernetes 集群有兩類用戶：由 Kubernetes 管理的Service Accounts （服務賬戶）和（Users Accounts） 普通賬戶。

普通賬戶是假定被外部或獨立服務管理的，由管理員分配 keys，用戶像使用 Keystone 或 google 賬號一樣，被存儲在包含 usernames 和 passwords 的 list 的文件里。

需要注意：在 Kubernetes 中不能通過 API 調用將普通用戶添加到集群中。

• 普通帳戶是針對（人）用戶的，服務賬戶針對 Pod 進程。
• 普通帳戶是全局性。在集群所有namespaces中，名稱具有惟一性。
• 通常，群集的普通帳戶可以與企業數據庫同步，新的普通帳戶創建需要特殊權限。服務賬戶創建目的是更輕量化，允許集群用戶為特定任務創建服務賬戶。
• 普通帳戶和服務賬戶的審核注意事項不同。
• 對于復雜系統的配置包，可以包括對該系統的各種組件的服務賬戶的定義。

Service Accounts

服務賬號以 ServiceAccount 對象的形式存在于 API 服務器中。服務賬號具有以下屬性：

• 名字空間限定： 每個服務賬號都與一個 Kubernetes 名字空間綁定。 每個名字空間在創建時，會獲得一個名為 default 的 ServiceAccount。

• 輕量級： 服務賬號存在于集群中，并在 Kubernetes API 中定義。你可以快速創建服務賬號以支持特定任務。

• 可移植性： 復雜的容器化工作負載的配置包中可能包括針對系統組件的服務賬號定義。 服務賬號的輕量級性質和名字空間作用域的身份使得這類配置可移植。

服務賬號與用戶賬號不同，用戶賬號是集群中通過了身份認證的人類用戶。默認情況下， 用戶賬號不存在于 Kubernetes API 服務器中；相反，API 服務器將用戶身份視為不透明數據。 你可以使用多種方法認證為某個用戶賬號。某些 Kubernetes 發行版可能會添加自定義擴展 API 來在 API 服務器中表示用戶賬號。

Service Account Admission Controller

通過 Admission Controller 插件來實現對 pod 修改，它是 apiserver 的一部分。創建或更新 pod 時會同步進行修改 pod。當插件處于激活狀態（在大多數發行版中都默認情況）創建或修改 pod 時，會按以下操作執行：

1. 如果 pod 沒有設置 ServiceAccount，則將 ServiceAccount 設置為 default。
2. 確保 pod 引用的 ServiceAccount 存在，否則將會拒絕請求。
3. 如果 pod 不包含任何 ImagePullSecrets，則將ServiceAccount 的 ImagePullSecrets 會添加到 pod 中。
4. 為包含 API 訪問的 Token 的 pod 添加了一個 volume。
5. 把 volumeSource 添加到安裝在 pod 的每個容器中，掛載在 /var/run/secrets/kubernetes.io/serviceaccount。

Token Controller

TokenController 作為 controller-manager 的一部分運行。異步執行:

• 觀察 serviceAccount 的創建，并創建一個相應的 Secret 來允許 API 訪問。
• 觀察 serviceAccount 的刪除，并刪除所有相應的ServiceAccountToken Secret
• 觀察 secret 添加，并確保關聯的 ServiceAccount 存在，并在需要時向 secret 中添加一個 Token。
• 觀察 secret 刪除，并在需要時對應 ServiceAccount 的關聯

Service Account Controller

Service Account Controller 在 namespaces 里管理ServiceAccount，并確保每個有效的 namespaces 中都存在一個名為 “default” 的 ServiceAccount。

授權(RBAC)

Role

代表一個角色，會包含一組權限，沒有拒絕規則，只是附加允許。它是 Namespace 級別的資源，只能作用與 Namespace 之內。

# 查看已有的角色信息
kubectl get role -n ingress-nginx -oyaml

demo文件

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:labels:app.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginxname: nginx-ingressnamespace: ingress-nginx
roles:
- apiGroups:- ""resources:- configmaps- pods- secrets- namespacesverbs:- get
- apiGroups:- ""resourceNames:- ingress-controller-label-nginxresources:- configmapsverbs:- get- update
- apiGroups:- ""resources:- configmapsverbs:- create

ClusterRole

功能與 Role 一樣，區別是資源類型為集群類型，而 Role 只在 Namespace

# 查看某個集群角色的信息
kubectl get clusterrole view -oyaml

RoleBinding

Role 或 ClusterRole 只是用于制定權限集合，具體作用與什么對象上，需要使用 RoleBinding 來進行綁定。

作用于 Namespace 內，可以將 Role 或 ClusterRole 綁定到 User、Group、Service Account 上。

# 查看 rolebinding 信息
kubectl get rolebinding --all-namespaces# 查看指定 rolebinding 的配置信息
kubectl get rolebinding <role_binding_name> --all-namespaces -oyaml

demo

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:......
roleRef:apiGroup: rbac.authorization.k8s.iokind: Rolename: nginx-ingress
subjects:
- kind: ServiceAccountname: nginx-ingress-serviceaccountnamespace: ingress-nginx

ClusterRoleBinding

與 RoleBinding 相同，但是作用于集群之上，可以綁定到該集群下的任意 User、Group 或 Service Account

注：這塊內容更多是需要運維人員去處理，對于開發，有一定理論基礎即可，后期要用再深究吧