Dex を使用して Kubernetes 認証を実装する方法の詳細な説明

Kubernetes は現在最も広く使用されているオープンソースのコンテナオーケストレーションプラットフォームですが、少なくともネイティブにはユーザーを作成および管理する手段がありません。ただし、複数の認証サービスに接続できるため、これは欠点ではありません。その結果、Dex は Kubernetes で利用できる最高の認証ソリューションの 1 つになりました。

この記事では、Kubernetes 用の Dex について詳しく説明します。 Dex が解決できる問題のいくつか、サードパーティの ID プロバイダーを使用して設定する際の概要、そして Dex がカバーしていない、まだ対処が必要ないくつかの問題について検討します。

Dexとは何ですか?

Dex は、CoreOS, Inc. がリリースしたオープンソースの CNCF サンドボックスプロジェクトおよび認証サービスであり、OpenID Connect (OIDC) を使用して Kubernetes やその他の OIDC 互換サービスをさまざまな ID プロバイダーにリンクします。言い換えれば、Dex は、kubectl、Okta、GitHub、Google、Microsoft、Linkedin などの広く使用されている ID プロバイダー間のブローカーと考えることができます。

Dex は Kubernetes と他の ID プロバイダー間のブリッジとして機能するため、管理者は複数のチームを持つ組織にとって不可欠な、集中的なユーザーおよびグループ管理を実装できます。

さらに、次のセクションで説明するように、Dex はセキュリティを強化し、Kubernetes に最新の便利なログインエクスペリエンスをもたらすこともできます。

Dex for Kubernetes はどのように機能しますか?

Dex の仕組みを詳しく説明する前に、Kubernetes 認証プロセスの仕組みを理解することが重要です。

Kubernetes クラスターと通信する場合、kubectl は実際には API サーバーと対話します。 API サーバーへのすべての HTTP リクエストに対して、認証プラグインはユーザー名、UID、およびグループを検索します。このような属性は、クライアント証明書、認証プロキシ、またはベアラートークンによって提供できます。ここで Dex が登場し、ID プロバイダーと kubectl クライアント間のブリッジとして機能します。

Dex は OIDC を使用するため、いわゆる「コネクタ」を使用してサードパーティの ID プロバイダーに保存されているユーザー情報にアクセスできます。これにより、Dex はユーザー情報をベアラートークンの形式で Kubernetes に転送し、認証プロセスを完了できるようになります。これらはすべて、シングルサインオン (SSO) プロセスを通じて実行されるため、ユーザーに対して透過的です。

さらに、次のセクションで説明するように、Dex によって送信される ID トークンには、ユーザー認証に使用できる情報が含まれています。

上記のプロセスは、Kubernetes での認証の仕組みを簡略化したものです。認証プロセスの詳細については、Kubernetes の公式ドキュメントをご覧ください。

(https://kubernetes.io/docs/reference/access-authn-authz/authentication/)

Dex はどのような問題を解決しますか?

すでに述べたように、Dex は管理者が組織の ID サービスプロバイダーを使用してユーザーとグループを管理できるようにすることで Kubernetes の機能を拡張します。

しかし、これは Dex が解決する唯一の問題ではありません。他にどのようなメリットがあるのか見てみましょう。

01安全性の向上

Dex は、Kubernetes クラスターのセキュリティをいくつかの方法で向上させます。

ID プロバイダーを通じてユーザーをクラスターにログインさせる安全な方法を提供します。

これにより、複数のユーザーに対して同じ kubeconfig ファイルを使用することによって生じるセキュリティリスクが排除されます。

監査ログを通じて各ユーザーが実行したアクションを効果的に検出できます。

時間制限のないベアラートークンを作成する慣行を排除します。

RBAC ルール (ゼロトラスト RBAC アクセス) を使用した効果的なユーザーおよびグループ管理により、認証および承認ポリシーの適用に役立ちます。

02柔軟性

組織ごとに独自の要件がありますが、Dex はほぼすべての ID プロバイダーと連携できるほど柔軟です。これは、Okta、GitHub、GitLab、Microsoft、Linkedin、OpenID Connect、OAuth 2.0、LDAP、SAML 2.0 プロトコルなどを使用するサービスで利用可能なコネクタによって証明されています。 Dex の詳細については、github アドレスをご覧ください。 (https://github.com/dexidp/dex)

03集中認証システムを提供する

小規模なチームにとって、Dex の実装は最適なソリューションではない可能性があります。ただし、さまざまなチームにまたがって数十人のユーザーがいる組織にとって、Dex は非常に強力なツールです。 kubeconfig ファイルを手動で作成、管理、配布する必要がないため、時間の節約とセキュリティの面で大きな利点があります。

さらに、Dex はよりきめ細かいアクセス制御を可能にすることで Kubernetes を補完します。次のセクションで説明するように、Dex は ID トークンの発行を制御し、その有効期間を指定できるようにします。これは、一時的なユーザーアクセスが関係する状況で便利です。

さらに、必要に応じてすべての ID トークンを取り消すこともできます。特定のユーザーまたはグループのアクセス権限を取り消すこともできます。

つまり、Dex を使用すると、効率的で使いやすい集中認証システムを Kubernetes に追加できます。

Dex を使用して Kubernetes で認証を設定する

すでに述べたように、Dex はコネクタを使用して Kubernetes と複数の ID プロバイダーをリンクするポータルとして機能します。

次の図は、シングルサインオンプロセスの概要を示しています。

認証プロセスでは、次の手順が実行されます。

エンドユーザーは Dex へのログイン要求を開始します。これは通常、ユーザーがシングルサインオンを開始する Web アプリケーションまたはポータルを通じて行われます。
Dex はこのリクエストをサードパーティの ID プロバイダー (Active Directory、Google、GitHub、Okta など) に転送します。これを実現するために、Dex は他のユーザー管理システムにクエリを実行するための一連のプロトコルを備えた「コネクタ」を使用します。
これらの「コネクタ」のおかげで、Dex は ID プロバイダーから名前、メール、一意の識別子、グループ、アクセストークンなどの関連するユーザー情報にアクセスできます。Okta の場合、このデータは ID トークンの形式で提供されます。 Dex のドキュメントによると、「ID トークンは JSON Web トークン (JWT) であり、エンドユーザーの ID を証明する OAuth2 応答の一部として返されます。」
Dex は、サードパーティのアップストリーム ID プロバイダーからユーザー情報を取得すると、ID プロバイダーの役割を引き受け、署名された ID トークンを kubectl クライアントに発行し、JWT を API サーバーに転送します。
API サーバーは、Kubernetes OpenID Connect Token Authenticator プラグインを使用して ID トークンを消費します。この時点での結果は、ユーザーを認証するか拒否するかになります。ユーザーが正常に認証されると、API サーバーは ID トークン情報を使用して RBAC ルールを適用します。
API サーバーからの応答が kubectl クライアントに送り返されます。
クライアントは kubectl の結果をエンドユーザーに表示します。

LDAP 経由の認証の詳細については、ここにあるドキュメントをお読みください。 Okta などの OpenID Connect プロバイダーで認証する方法の詳細については、ここにあるドキュメントを参照してください。

Dex が解決しない問題は何ですか?

Dex は、Kubernetes のシングルサインオンエクスペリエンスを求める組織に優れたソリューションを提供しますが、特定の ID プロバイダーに関連する制限から免除されるわけではありません。

Dex のドキュメント (https://github.com/dexidp/dex) に示されているように、すべての ID プロバイダーが更新トークン要求をサポートしているわけではありません。つまり、アイデンティティプロバイダーによっては、ユーザーは前のセクションで説明した認証プロセスを定期的に繰り返す必要があります。

さらに、すべての Dex コネクタが安定しているわけではありません。 Google、Bitbucket Cloud、OAuth 2.0 のコネクタはまだアルファ版です。

留意すべきもう 1 つの点は、Dex は認証ソリューションとしてのみ使用されるということです。環境変数、kube コンテキスト、コストの管理は、手動または他のツールを使用して行う必要があります。