認證用於身份鑒別，而授權則實現權限分派。k8s以插件化的方式實現了這兩種功能，且分別存在多種可用的插件。另外，它還支持准入控制機制，用於補充授權機制以實現更精細的訪問控制功能。
一、訪問控制概述
apiserver作為k8s集群系統的網關，是訪問及管理資源對象的唯一入口，余下所有需要訪問集群資源的組件，包括kube-controller-manager、kube-scheduler、kubelet和kube-proxy等集群基礎組件、CoreDNS等集群的附加組件以及此前使用的kubectl命令等都要經由此網關進行集群訪問和管理。這些客戶端均要經由apiserver訪問或改變集群狀態並完成數據存儲，並由它對每一次的訪問請求進行合法性檢驗，包括用戶身份鑒別、操作權限驗證以及操作是否符合全局規范的約束等。所有檢查均正常且對象配置信息合法性檢驗無誤后才能訪問或存入數據於后端存儲系統etcd中。
客戶端認證操作由apiserver配置的一到多個認證插件完成。收到請求后，apiserver依次調用為其配置的認證插件來認證客戶端身份，直到其中一個插件可以識別出請求者的身份為止。授權操作由一到多授權插件進行，它負責確定那些通過認證的用戶是否有權限執行其發出的資源操作請求，如創建、刪除或修改指定的對象等。隨后，通過授權檢測的用戶所請求的修改相關的操作還要經由一到多個准入控制插件的遍歷檢測。
1、用戶賬戶與用戶組
k8s並不會存儲由認證插件從客戶端請求中提取出的用戶及所屬組的信息，他們僅僅用於檢測用戶是否有權限執行其所請求的操作。客戶端訪問api服務的途徑通常有三種：kubectl、客戶端庫或者直接使用rest接口進行請求，而可以執行此類請求的主體也被k8s分為兩類：現實中的人和pod對象，它們的身份分別對應於常規用戶和服務賬號。
useraccount（用戶賬號）：一般是指由獨立於k8s之外的其他服務管理的用戶賬號，例如由管理員分發的密鑰、keystore一類的用戶存儲、甚至是包含用戶名和密碼列表的文件等。k8s中不存在表示此類用戶賬號的對象，因此不能被直接添加進k8s系統中。
serviceaccount（服務賬號）：是指由k8sapi管理的賬號，用於為pod之中的服務進程在訪問k8sapi時提供身份標識。serviceaccount通常要綁定與特定的名稱空間，它們由apiserver創建，或者通過api調用手動創建，附帶着一組存儲為secret的用於訪問apiserver的憑據。
useraccount通常用於復雜的業務邏輯管控，它作用於系統全局，故其名稱必須全局唯一。相比較來說，serviceaccount隸屬於名稱空間，僅用於實現某些特定的操作任務，因此要輕量得多。這兩類賬號都可以隸屬於一個或多個用戶組。用戶組只是用戶賬號的邏輯集合，它本身並沒有操作權限，但附加於組上的權限可由其內部的所有用戶繼承，以實現高效的授權管理機制。
system: unauthenticated: 未能通過任何一個授權插件檢驗的賬號，即未通過認證測試的用戶所屬的組。
system:authenticated: 認證成功后的用戶自動加入的一個組，用於快捷引用所有正常通過認證的用戶賬號。
system:serviceaccounts：當前系統上的所有service account對象。
system:serviceaccounts:<namespace>:特定名稱空間內所有的serviceaccount對象。
api請求要么與普通用戶或服務賬戶進行綁定，要么被視為匿名請求。這意味着集群內部或外部的每個進程，包括由人類用戶使用的kubectl，到節點上的kubelet，再到控制平面的成員組件，必須在向api服務器發出請求時進行身份驗證，否則即被視為匿名用戶。
2、認證、授權與准入控制基礎
api server處理請求的過程中，認證插件負責鑒定用戶身份，授權插件用於操作權限許可鑒別，而准入控制則用於在資源對象的創建、刪除、更新或連接操作時實現更精細的許可檢查。
kubernetes使用身份驗證插件對api請求進行身份驗證，支持的認證方式包括客戶端證書、承載令牌、身份驗證代理或http basic認證等。api server接收到訪問請求時，它將調用認證插件嘗試將以下屬性與訪問請求相關聯。
Username: 用戶名，如kubernetes-admin等。
UID：用戶的數字標簽符，用於確保用戶身份的唯一性。
Groups：用戶所屬組，用於權限指派和繼承
Extra：鍵值數據類型的字符串，用於提供認證時需要用到的額外信息。
api server支持同時啟用多種認證機制，但至少應該分別為service account和user account各自啟用一個認證插件。同時啟用多種認證機制時，認證過程會以串行的方式進行，直到一種認證機制成功完成即結束。若認證失敗，則服務器會響應401狀態碼，反之，請求者就會被識別為某個具體的用戶，並且隨后的操作都將以此用戶身份來進行。