2. 程式人生 > >使用kubectl訪問Kubernetes叢集時的身份驗證和授權

使用kubectl訪問Kubernetes叢集時的身份驗證和授權

阿新 • • 發佈：2018-12-20

當我們使用kubeadm成功引導啟動(init)一個Kubernetes叢集的控制平面後，kubeadm會在init的輸出結果中給予我們下面這樣的“指示”：

`... ...
Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config
... ...
`

kubeadm init在結尾處輸出的這些資訊是在告知我們如何配置kubeconfig檔案。按照上述命令配置後，master節點上的kubectl就可以直接使用$HOME/.kube/config的資訊訪問k8s cluster了。並且，通過這種配置方式，kubectl也擁有了整個叢集的管理員(root)許可權。

很多K8s初學者在這裡都會有疑問：當kubectl使用這種kubeconfig方式訪問叢集時，Kubernetes的kube-apiserver是如何對來自kubectl的訪問進行身份驗證(authentication)和授權(authorization)的呢？為什麼來自kubectl的請求擁有最高的管理員許可權呢？在本文中，我們就來分析說明一下這個過程。

一. Kubernetes API的訪問控制原理回顧

在《Kubernetes的安全設定》一文中我曾介紹過Kubernetes叢集的訪問許可權控制由kube-apiserver負責，kube-apiserver的訪問許可權控制由身份驗證(authentication)、授權(authorization)和准入控制（admission control）三步驟組成，這三步驟是按序進行的：

這裡寫圖片描述

要想搞明白kubectl訪問Kubernetes叢集時的身份驗證和授權，就是要弄清kube-apiserver在進行身份驗證和授權兩個環節都做了什麼：

  • Authentication：即身份驗證，這個環節它面對的輸入是整個http request，它負責對來自client的請求進行身份校驗，支援的方法包括：client證書驗證（https雙向驗證）、basic auth、普通token以及jwt token(用於serviceaccount)。APIServer啟動時，可以指定一種Authentication方法，也可以指定多種方法。如果指定了多種方法，那麼APIServer將會逐個使用這些方法對客戶端請求進行驗證，只要請求資料通過其中一種方法的驗證，APIServer就會認為Authentication成功；在較新版本kubeadm引導啟動的k8s叢集的apiserver初始配置中，預設支援client證書驗證和serviceaccount兩種身份驗證方式。在這個環節，apiserver會通過client證書或http header中的欄位(比如serviceaccount的jwt token)來識別出請求的“使用者身份”，包括”user”、”group”等，這些資訊將在後面的authorization環節用到。

  • Authorization：授權。這個環節面對的輸入是http request context中的各種屬性，包括：user、group、request path（比如：/api/v1、/healthz、/version等）、request verb(比如：get、list、create等)。APIServer會將這些屬性值與事先配置好的訪問策略(access policy）相比較。APIServer支援多種authorization mode，包括Node、RBAC、Webhook等。APIServer啟動時，可以指定一種authorization mode，也可以指定多種authorization mode，如果是後者，只要Request通過了其中一種mode的授權，那麼該環節的最終結果就是授權成功。在較新版本kubeadm引導啟動的k8s叢集的apiserver初始配置中，authorization-mode的預設配置是”Node,RBAC”。Node授權器主要用於各個node上的kubelet訪問apiserver時使用的，其他一般均由RBAC授權器來授權。

RBAC，Role-Based Access Control即Role-Based Access Control，它使用”rbac.authorization.k8s.io”實現授權決策，允許管理員通過Kubernetes API動態配置策略。在RBAC API中，一個角色(Role)包含了一組許可權規則。Role有兩種：Role和ClusterRole。一個Role物件只能用於授予對某一單一名稱空間（namespace）中資源的訪問許可權。ClusterRole物件可以授予與Role物件相同的許可權，但由於它們屬於叢集範圍物件， 也可以使用它們授予對以下幾種資源的訪問許可權：

  • 叢集範圍資源（例如節點，即node）
  • 非資源型別endpoint（例如”/healthz”）
  • 跨所有名稱空間的名稱空間範圍資源（例如所有名稱空間下的pod資源)

rolebinding，角色繫結則是定義了將一個角色的各種許可權授予一個或者一組使用者。 角色繫結包含了一組相關主體（即subject, 包括使用者——User、使用者組——Group、或者服務賬戶——Service Account）以及對被授予角色的引用。 在名稱空間中可以通過RoleBinding物件進行使用者授權，而叢集範圍的使用者授權則可以通過ClusterRoleBinding物件完成。

好了，有了上面這些知識基礎，要搞清楚kubectl訪問叢集的身份驗證和授權過程，我們只需要逐一解決下面的一些問題即可：

1、authencation中識別出了哪些http request context中的資訊？ 2、authorization中RBAC authorizer找到的對應的rolebinding或clusterrolebinding是什麼？ 3、對應的role或clusterrole的許可權規則？

二. 在身份驗證(authentication)識別出Group

我們先從kubectl使用的kubeconfig入手。kubectl使用的kubeconfig檔案實質上就是kubeadm init過程中生成的/etc/kubernetes/admin.conf，我們檢視一下該kubeconfig檔案的內容：

環境k8s 1.10.3:

# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://172.16.66.101:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: [email protected]
current-context: [email protected]
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

關於kubeconfig檔案的解釋，可以在這裡自行腦補。在這些輸出資訊中，我們著重提取到兩個資訊：

user name: kubernetes-admin
client-certificate-date: XXXX

前面提到過apiserver的authentication支援通過tls client certificate、basic auth、token等方式對客戶端發起的請求進行身份校驗，從kubeconfig資訊來看，kubectl顯然在請求中使用了tls client certificate的方式，即客戶端的證書。另外我們知道Kubernetes是沒有user這種資源的，通過k8s API也無法建立user。那麼kubectl的身份資訊就應該“隱藏”在client-certificate的資料中，我們來檢視一下。

首先我們將 /etc/kubernetes/admin.conf中client-certificate-data的資料內容儲存到一個臨時檔案admin-client-certificate.txt中：

// admin-client-certificate.txt

LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM4akNDQWRxZ0F3SUJBZ0lJZjJkVlJqbThFTFF3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB4T0RBMU1UUXdPREUzTVROYUZ3MHhPVEExTVRRd09ERTNNVGRhTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXhCbjNqZHc4MGIxR2ZiNnMKdzJOcnFwTG90TVQ0bnlBZjJIaHFNclhqbk8rd25hSzFBSVRPdy8yMm1EajByd0l1SndkUUlqNS9CYUY2M3BQRQoxcFUwdmhJUFZLNG42Skk0ZG1Nem8vbFIzalpwR2VaVzF6ZFhhQ292dzljN2NsYmlIby9tRkc0eHF5dFZMZlg0Ci9TOG1GcDJBOVFjaWVKR0lvNVMwQlIzRlpsVTFQTTdEUmJMRFZWcTFQZHlOWTJHZnNiR3JIbEdnWHZXQUtDZC8KSDc5Z0FxVm9UWGpTSVdDVll1WWNvTHZkdlZYUVNJaVlscFhGUDFqQlFMdmNVN3ZycXRiMTJSbXJ4bnBrVzRwbApkR0VPWDJzTG1mWVo1VGlGcGtSd3oyR3hzbVd5UmJ0Nk91SVNKRkk2UlowcitSbjR5TURLUHJZbEVuZ0RWYzVLClBaNXptd0lEQVFBQm95Y3dKVEFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFFWk5UdlR6Mk9nekNVZHZNRmJyaFBzcCttRDJ2UGpNUkN4aQozQmtBMTB2SUNPU2ZkeW1NbjhhdzBJYktZejJnUWJYcVVmcXpRbVFmYTNpZitRWUJrQis3N3pmc3Y5YW00RVAvCmU2VGc1MnRxVjJQN3MyZUY3dE5BZTIwR3lWNnlGbFExUVVXNS9NNE0rSk1sVitCVWJsOXlFeVFsRU51Y0tmK3UKVFB5S0tUVXR6dlVZcjVFM0VKa3Q4NEVRSU52dzJuUjJqTnZlWjFYV09saVVyS2ZqSEh0ZnZPL241NlVTdUk0dwp1MkxUbElDUmNqNGcrWldsSWplTUZrR3lQYkp5SkFRNjVQMnNHclptMWtsR0dIM216d081Q1AxeVpXdm9VampQCmp6U2pNQ0lhSy9mUjhlUkFKNnExdFQ2YkcyNkwrbmprS0NRRFdLcGpBV09hcHVST2Niaz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=

然後針對該檔案資料做base64解碼，得到client certificate檔案：

cat admin-client-certificate.txt | base64 -d > admin-client.crt

# cat admin-client.crt

-----BEGIN CERTIFICATE-----
MIIC8jCCAdqgAwIBAgIIf2dVRjm8ELQwDQYJKoZIhvcNAQELBQAwFTETMBEGA1UE
AxMKa3ViZXJuZXRlczAeFw0xODA1MTQwODE3MTNaFw0xOTA1MTQwODE3MTdaMDQx
FzAVBgNVBAoTDnN5c3RlbTptYXN0ZXJzMRkwFwYDVQQDExBrdWJlcm5ldGVzLWFk
bWluMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxBn3jdw80b1Gfb6s
w2NrqpLotMT4nyAf2HhqMrXjnO+wnaK1AITOw/22mDj0rwIuJwdQIj5/BaF63pPE
1pU0vhIPVK4n6JI4dmMzo/lR3jZpGeZW1zdXaCovw9c7clbiHo/mFG4xqytVLfX4
/S8mFp2A9QcieJGIo5S0BR3FZlU1PM7DRbLDVVq1PdyNY2GfsbGrHlGgXvWAKCd/
H79gAqVoTXjSIWCVYuYcoLvdvVXQSIiYlpXFP1jBQLvcU7vrqtb12RmrxnpkW4pl
dGEOX2sLmfYZ5TiFpkRwz2GxsmWyRbt6OuISJFI6RZ0r+Rn4yMDKPrYlEngDVc5K
PZ5zmwIDAQABoycwJTAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUH
AwIwDQYJKoZIhvcNAQELBQADggEBAEZNTvTz2OgzCUdvMFbrhPsp+mD2vPjMRCxi
3BkA10vICOSfdymMn8aw0IbKYz2gQbXqUfqzQmQfa3if+QYBkB+77zfsv9am4EP/
e6Tg52tqV2P7s2eF7tNAe20GyV6yFlQ1QUW5/M4M+JMlV+BUbl9yEyQlENucKf+u
TPyKKTUtzvUYr5E3EJkt84EQINvw2nR2jNveZ1XWOliUrKfjHHtfvO/n56USuI4w
u2LTlICRcj4g+ZWlIjeMFkGyPbJyJAQ65P2sGrZm1klGGH3mzwO5CP1yZWvoUjjP
jzSjMCIaK/fR8eRAJ6q1tT6bG26L+njkKCQDWKpjAWOapuROcbk=
-----END CERTIFICATE-----

檢視證書內容：

# openssl x509 -in ./admin-client.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 9180400125522743476 (0x7f67554639bc10b4)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: May 14 08:17:13 2018 GMT
            Not After : May 14 08:17:17 2019 GMT
        Subject: O=system:masters, CN=kubernetes-admin
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)

   ... ...

從證書輸出的資訊中，我們看到了下面這行：

Subject: O=system:masters, CN=kubernetes-admin

k8s apiserver對kubectl的請求進行client certificate驗證(通過ca證書–client-ca-file=/etc/kubernetes/pki/ca.crt對其進行校驗)，驗證通過後kube-apiserver會得到：group = system:masters的http上下文資訊，並傳給後續的authorizers。

三. 在授權(authorization)時根據Group確定所繫結的角色(Role)

kubeadm在init初始引導叢集啟動過程中，建立了許多default的role、clusterrole、rolebinding和clusterrolebinding，在k8s有關RBAC的官方文件中，我們看到下面一些default clusterrole列表:

這裡寫圖片描述

其中第一個cluster-admin這個cluster role binding綁定了system:masters group，這和authentication環節傳遞過來的身份資訊不謀而合。沿著system:masters group對應的cluster-admin clusterrolebinding“追查”下去，真相就會浮出水面。

我們檢視一下這一binding：

# kubectl get clusterrolebinding/cluster-admin -n kube-system -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: 2018-06-07T06:14:55Z
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "103"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin
  uid: 18c89690-6a1a-11e8-a0e8-00163e0cd764
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

我們看到在kube-system名字空間中，一個名為cluster-admin的clusterrolebinding將cluster-admin cluster role與system:masters Group繫結到了一起，賦予了所有歸屬於system:masters Group中使用者cluster-admin角色所擁有的許可權。

我們再來檢視一下cluster-admin這個role的具體許可權資訊：

# kubectl get clusterrole/cluster-admin -n kube-system -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: 2018-06-07T06:14:55Z
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "52"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/cluster-admin
  uid: 18abe535-6a1a-11e8-a0e8-00163e0cd764
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
- nonResourceURLs:
  - '*'
  verbs:
  - '*'

從rules列表中來看，cluster-admin這個角色對所有resources、verbs、apiGroups均有無限制的操作許可權，即整個叢集的root許可權。於是kubectl的請求就可以操控和管理整個叢集了。

四. 小結

至此，我們應該明確了為什麼採用了admin.conf kubeconfig的kubectrl擁有root許可權了。下面是一幅示意圖，簡要總結了對kubectl訪問請求的身份驗證和授權過程：

這裡寫圖片描述

相關推薦

使用kubectl訪問Kubernetes叢集時的身份驗證和授權

當我們使用kubeadm成功引導啟動(init)一個Kubernetes叢集的控制平面後，kubeadm會在init的輸出結果中給予我們下面這樣的“指示”： `... ... Your Kubernetes master has initialized suc

mongo的身份驗證和授權

配置 登陸 同名 以及 意思 margin info 它的 只讀 問題來源剛裝好的mongo，準備登陸進去測一把的，結果就給我報這個錯，鄙人是新手，還不太清楚這個，現學一下~Mongo的身份驗證在上一篇安裝mongo的博客中（https://www.cnblogs.com/

ASP.NET Core 2.0身份驗證和授權系統揭祕

ASP.NET Core中存在一個元件，它構成了一個魔法遮蔽，可以保護您網站的部分（或全部）免受未經授權的訪問。像許多人一樣，我從旅程開始就使用過這個元件，但從未理解過。它被一個巫師召喚出來，在我的網站和世界之間提供了一個神奇的屏障。當然，這不是它真正起作用的方式，但如果沒有正確的知識，它也可能。

Kubernetes身份認證和授權操作全攻略：K8s 訪問控制入門

隨著Kubernetes被廣泛使用，成為業界公認的容器編排管理的標準框架，許多開發人員以及管理員對部署、彈性伸縮以及管理容器化應用

kubectl管理kubernetes叢集

[[email protected] ~]# kubectl get nodes  檢視叢集節點NAME      STATUS    AGEnode1     Read

使用kubectl檢視Kubernetes叢集裡的node節點資訊

使用命令列拿到當前Kubernetes叢集的所有節點： kubectl get nodes 檢視某個節點的明細： kubectl describe node shoot--k8s-train--shacw46-worker-l9qsr-z1-5869bb9948-4c

傳統身份驗證和JWT的身份驗證

轉自：https://ninghao.net/blog/2834 1、傳統身份驗證和JWT的身份驗證 傳統身份驗證： HTTP 是一種沒有狀態的協議，也就是它並不知道是誰是訪問應用。這裡我們把使用者看成是客戶端，客戶端使用使用者名稱還有密

如何從外部訪問Kubernetes叢集中的應用？\

前言 我們知道，kubernetes的Cluster Network屬於私有網路，只能在cluster Network內部才能訪問部署的應用，那如何才能將Kubernetes叢集中的應用暴露到外部網路，為外部使用者提供服務呢？本文探討了從外部網路訪問kubernetes

探索ASP.NET Identity 身份驗證和基於角色的授權，中級篇

在前一篇文章中，我介紹了ASP.NET Identity 基本API的運用並建立了若干使用者賬號。那麼在本篇文章中，我將繼續ASP.NET Identity 之旅，向您展示如何運用ASP.NET Identity 進行身份驗證（Authentication）以及聯合ASP.N

在Openstack上建立並訪問Kubernetes叢集_Kubernetes中文社群

第一部分：建立叢集 在Openstack部署Kubernetes叢集執行Nginx容器的步驟，其中包括： 利用Murano部署Kubernetes叢集 配置Openstack的安全性使Kubernetes叢集可以在Openstack使用 下載並配置kubernetes客戶端 建立Kubern

Django中用Jquery實現不重新整理頁面進行身份驗證和計算器功能

1.下載jquery http://www.jq22.com/jquery-info122 下載解壓之後加入工程中的static資料夾中 2.路由分發。 """Django_demo1 URL Configuration The `urlpatterns` list routes URLs

基於Token實現身份驗證和許可權管理

一、什麼是token HTTP是一種無狀態的協議，也就是HTTP沒法儲存客戶端的資訊，沒辦法區分每次請求的不同。 Token是伺服器生成的一串字元，作為客戶端請求的令牌。當第一次登陸後，伺服器會分發Tonken字串給客戶端。後續的請求，客戶端只需帶上這個Token，伺服器即可知

SQL Server 2014 windows身份驗證和sa登入失敗，且忘記密碼的解決辦法

【1】 停止SQL Server 服務 和 SQL Server Agent 服務【2】 以管理員身份開啟命令列，單使用者模式啟動服務。（在單使用者模式下啟動 SQL Server 可使計算機本地 Administrators 組的任何成員作為 sysadmin 固定伺服器角

spring Aop實現身份驗證和springboot異常統一處理

文章有不當之處，歡迎指正，如果喜歡微信閱讀，你也可以關注我的微信公眾號：好好學java，獲取優質學習資源。 一、spring Aop身份驗證 一般，如果使用者沒有登入的話，使用者只可以檢視商品，但是其他的，比如支付等是不能夠進行操作的，這個時候，我們

如何從外部訪問Kubernetes叢集中的應用？

前言 我們知道，kubernetes的Cluster Network屬於私有網路，只能在cluster Network內部才能訪問部署的應用，那如何才能將Kubernetes叢集中的應用暴露到外部網路，為外部使用者提供服務呢？本文探討了從外部網路訪問k

菜鳥學習shiro之實現自定義的Realm，從而實現登入驗證，身份驗證和許可權驗證4

講了那麼多使用的內建的類從而實現四郎，現在講自定義的境界 首先行家的依賴依然是第一篇的那個依賴 下邊是自定義的境界： import org.apache.shiro.authc.AuthenticationException; import org.apache.shi

Azure AD：基於宣告的驗證和授權

Azure AD：基於宣告的驗證和授權 概念： 使用者及其屬性：使用者指的是要使用某項服務的個體，其屬性是指與之相關的使用者名稱、角色、郵件地址等； 宣告（Claim）：對某個個體的某項屬性的一個確定的陳述（Assertion），例如，這個使用者是Jeffrey

Django2.0-驗證和授權(4)-Group 分組

分組 許可權有很多，一個模型就有最少三個許可權，如果一些使用者擁有相同的許可權，那麼每次都要重複新增。 這時候分組就可以幫解決這種問題了，可以把一些許可權歸類，然後新增到某個分組中，之後再把需要賦予這些許可權的使用者新增到這個分組中，就比較好管理了。 分組使用的是

Django2.0-驗證和授權(4)-許可權

許可權 Django中內建了許可權的功能。 都是針對表（模型級別）的。比如對某個模型上的資料是否可以進行增刪改查操作。 不能針對資料級別的，比如對某個表中的某條資料能否進行增刪改查操作（如果要實現資料級別的，考慮使用django-guardian）。 建立

Django2.0-驗證和授權(3)-User登陸，登出，登陸限制

登入、登出和登入限制 登入 在使用authenticate進行驗證後，如果驗證通過了。那麼會返回一個user物件，拿到user物件後，可以使用django.contrib.auth.login進行登入。 這裡使用的models是繼承自AbstractBaseUser的模型