要讓 kubectl 之類的 command line tool 能透過 id_token 進行操作，要設定三個地方。
第一個是先用 kubectl 設定 ~/.kube/config 裡的 context。先假設已經設定好 cluster ，且 cluster 名稱為 kubernetes ，只需要設定 user 和 context 的部分。
kubectl config set-credentials dex --token=
kubectl config set-context dex --cluster=kubernetes --user=dex --namespace=default
kubectl config use-context dex
user 和 context 名稱隨便設定，兩者有對應起來就好，我這邊是都用 dex。設定完之後可以檢查一下 ~/.kube/config 確認設定是否正確。
這時用 kubectl 試看看，例如 kubectl get nodes，會出現類似 「server 沒有相關資源」錯誤訊息。
接下來是 kubernetes 的 APISERVER，如果是用 kubeadm 安裝的，設定檔會在 /etc/kubernetes/manifests/kube-apiserver.yaml。簡報那頁裡的三個設定項是必要的，另外還要設定 dex 使用的金鑰憑證 (ca.pem)，最後因為我設定的 OpenID scope 裡還包含 groups ，所以還要加上 groups claim 的參數，所以最後在 APISERVER 加上的參數是
- --oidc-issuer-url=https://dex2.example.com:32200
- --oidc-client-id=php-oidc
- --oidc-username-claim=email
- --oidc-groups-claim=groups
- --oidc-ca-file=/etc/kubernetes/pki/oidc.pem
最後一個參數要說明一下，為了方便辨識，所以把 ca.pem 更名為 oidc.pem，而要注意的是 kube-apiserver 是個 static pod，所以要把檔案放在這個 pod 能讀取到的路徑，這部分在之前有關 kubernetes audit 的文章內有說明過。
確認 kube-apiserver 重啟且運作正常後，再用 kubectl get nodes 試看看，如果設定正確的話，會出現不一樣的錯誤訊息，類似「使用者 xxx 沒有 list nodes 資源的權限」。很好，這表示 APISERVER 可以驗證出 token 裡的身份權限。
最後就是設定 kubernetes RBAC 權限，讓 token 裡的 user/group 可以有權限操作 kubernetes。因為我有設定 groups claim，所以 APISERVER 是可以認得的。另外要注意的是 groups claim 雖然是 Array 形式，但是在比對 RBAC 權限時，會比對陣列裡的每一個項目。
為了測試方便，設定用現有的 clusterrole ，例如 cluster-admin 。而我設定 LDAP 傳回的 groups 是一個只有包含名稱為 brobridge 的陣列，所以設定如下的 RBAC yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: managers-oidc
subjects:
- kind: Group
name: brobridge
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
建立這個權限後，再用 kubectl get nodes 測試看看，可以了!
以上只是基本的設定，從官網和簡報中可以知道，在授權的部分 (即 Authz )，可以透過 websocket 方式來取得權限，就不需要自行根據每個 user/group 去寫 yaml 來設定權限。
不過這部分和 dex 比較沒有直接關係，而且這方式通常要接外部現有的系統，我這邊沒有類似的環境，所以就沒有進行了。
另外這幾篇也沒有提到 token 過期時，要 refresh token 的方法。
下一篇會討論需要補強及一些細節的地方。
沒有留言:
張貼留言