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日正式上課，點選閱讀原文連結即可報名。