歡迎光臨
每天分享高質量文章

Kubernetes實現SSO登錄之命令列體驗

上一篇文章中,我們討論了Kubernetes的幾種用戶認證方法,還說了我的團隊在Pusher希望為我們的工程師創建一個無縫的SSO(單點登錄)環境,以及是如何開始對Open ID Connect(OIDC)進行調查並找出解決方案的。
這其中有個問題是Kubernetes沒有登錄的過程。通常,客戶端軟體會啟動登錄,但kubectl沒有內置該功能。Kubernetes留給你去設計你自己的登錄方式。
這篇文章,我將闡述如何實現讓工程師從終端登錄以及我們在這過程中趟過的坑。

我們的身份提供商

實現SSO的第一步是把Dex設置為我們的身份提供商。Dex充當認證流程的代理,用Google GSuite帳戶對用戶進行身份驗證。
我們在Elastic Load Balancer後面使用AWS EC2實體集運行Dex,暴露一臺Dex來驗證所有Pusher內部的Kubernetes集群。雖然可以在Kubernetes中運行Dex,在各個集群分別驗證,但我們選擇了集中的方式。這意味著允許一個令牌訪問所有群集,但考慮到想用Dex撤銷令牌的功能,我們決定接受這個折衷的結果。
Kubernetes集群連接到Dex,只在Kubernetes API服務器的配置中添加一些引數:
# The URL where Dex was available
--oidc-issuer-url=https://auth.example.com/dex
# The client ID we configured in dex. Kubernetes will compare this to the `aud` field
# in any bearer token from Dex before accepting it.
--oidc-client-id=kubernetes
# Since Dex is configured with TLS, add the CA cert to initiate trust
--oidc-ca-file=/etc/kubernetes/ssl/dex-ca.pem
# The claim field to identify users. For us this means users are granted the username # of their Pusher email address
--oidc-username-claim=email
當使用Dex集群生成的ID令牌時,Kubernetes可以驗證令牌並使用令牌驗證用戶。
當前的Dex版本不支持用OIDC連接器進行令牌掃清,所以Dex不會傳回Google去確認該用戶是否還具備登錄權限。對此,我們已經在Github提交了請求[1],並且目前用我們的自定義實現。

連接kubectl——錯誤的打開放式

開始接觸Dex,我用他們的示例程式[2]生成了第一個ID令牌。
staticClients:
- id: kubernetes
redirectURIs:
- 'http://127.0.0.1:5555/callback' # Allowed redirect URI
name: 'Kubernetes API'
secret: # Pre-shared client-application secret
通過給Dex添加靜態客戶端並回呼到127.0.0.1,我可以在筆記本電腦上運行示例程式,並用它生成我的第一個令牌。註意,Dex不會直接與應用程式交互,因此可以在回呼地址上配置客戶端。
Dex(和其他OIDC提供商)使用redirectURI的白名單來驗證請求用戶令牌的軟體身份。認證過程的令牌交換階段,通過向Dex發送包含redirectURI的初始請求,Dex向其已知的客戶端(這次的場景是使用ID kubernetes)簽發ID令牌,並期待客戶端軟體提供匹配的共享密鑰。這保證了可信度並防止中間過程的人為攻擊。

./example-app -client-id=kubernetes -client-secret= -issuer=https://auth.example.com/dex -issuer-root-ca=ca.pem

上述命令啟動了一個Web服務器,並監聽127.0.0.1:5555(你可能註意到這正是Dex中redirectURI的一部分)。通過訪問該地址,我可以開始登錄流程,並生成一個ID令牌和一個掃清令牌。
有了這些信息,我在kubeconfig檔案中添加瞭如下內容:
- name: joel.speed@pusher.com
user:
auth-provider:
config:
client-id: kubernetes
client-secret: # Pre-shared client auth
id-token:
idp-issuer-url: https://auth.example.com/dex
refresh-token:
name: oidc
kubectl可以用該配置與Kubernetes群集交互,當ID令牌過期時,可以用掃清令牌獲取新的ID令牌。
雖然這次嘗試還算成功,但我不想推廣這種登錄方式,而想創建一個用戶友好的登錄方式。對我而言,這種需要檢索密鑰,運行一個工具,然後將信息從瀏覽器複製到kubeconfig的方式,算不上用戶友好的方式。

連接kubectl——用戶友好的方式

為了改善用戶體驗,我通過gcloud身份驗證登錄流程找尋靈感。如果你沒有體驗過gcloud登錄,則可以在終端用命令打開瀏覽器的方式,打開Google的登錄畫面。登錄後,它會指示您傳回終端,告知您已登錄且您的環境已配置。從Dex示例應用程式開始一步一步,我創建了一個工具(稱為k8s-auth)。
作為入職的一部分,Pusher的工程師需要簽入Vault。k8s-auth正是利用了這一點。我們在Vault中儲存了k8s-auth的配置,在運行時使用工程師的Vault令牌將其加載到程式。因此,假如我們要改共享的客戶端密鑰,我們只需要更新Vault。
k8s-auth使用kubernetes客戶端庫中的代碼為該用戶配置kubeconfig,而不是在Web瀏覽器中出示令牌。由於我們的集群遵循命名規則,因此我還添加了一項功能,將新集群和相應背景關係配置為同一應用程式的一部分。
當新工程師加入時,為了配置kubectl並連接到我們的集群,他們按照以下說明操作:
  • 按照我們的入職說明登錄Vault

  • 安裝k8s-auth和kubectl

  • 運行k8s-auth cluster1 cluster2

  • 運行kubectl config set-context來選擇群集

如果我們撤銷了他們的令牌,他們只需要運行一次k8s-auth來生成一個新的ID令牌和refresh令牌。

總結

我們希望用戶友好的SSO登錄,能讓我們的工程師可以更好的使用kubectl。我們發現我們喜歡gcloud的身份驗證登錄方式,併成功實現了。
通過對原有的擴展以及將集群的配置整合到同一個工具,我們的工程師現在可以通過一種簡單的方式,對現有的及以後的集群進行kubectl配置。
雖然我無法開源我們特定版本的k8s-auth,但我創建了一個抽象版的例子[3]。你可以原封不動使用該例子來體驗OIDC登錄流程,也可以將其作為你自己創建集群登錄工具的範本。
話說,kubectl並不是工程師們訪問API的唯一途徑。Kubernetes Dashboard也不提供OIDC的登錄方法。在下一篇文章中,我將介紹我們設計的Dashboard SSO登錄方式,以及它的實現方法。
相關鏈接:
  1. https://github.com/coreos/dex/pull/1180

  2. https://github.com/coreos/dex/tree/master/cmd/example-app

  3. https://github.com/pusher/k8s-auth-example

原文鏈接:https://thenewstack.io/single-sign-kubernetes-command-line-experience/
Kubernetes入門與進階實戰培訓

本次培訓內容包括:Docker基礎、容器技術、Docker鏡像、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心組件原理分析、Kubernetes服務質量保證、調度詳解與應用場景、網絡、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等,點擊瞭解具體培訓內容
6月22日正式上課,點擊閱讀原文鏈接即可報名。
赞(0)

分享創造快樂