Red Hat OpenShift およびマイクロサービス・アーキテクチャでの認証と認可

コンテナベース・アーキテクチャの主要コンポーネントの 1 つは、セキュリティです。

セキュリティにはさまざまな側面があります (こちらの OpenShift 公式ドキュメントでトピックの一覧を参照してください) が、最も基本的な要件として認証と認可が挙げられます。この記事では、Kubernetes と Red Hat OpenShift での認証と認可の仕組みについて説明します。また、インフラストラクチャ・レイヤー、Kubernetes レイヤー、コンテナ化アプリケーション・レイヤーなど、Kubernetes エコシステムのさまざまなレイヤー間のインタラクションについて触れます。

認証と認可とは

簡単に言えば、コンピュータシステムにおける認証とは「あなたは誰ですか？」に答えるための方法です。一方の認可は、「本人であることがわかりました。では、あなたには何が許可されていますか？」に回答するものです。

私の経験では、Kubernetes においてこのトピックを理解する難しさは、ほとんどの場合、相互にやり取りするコンポーネント (ユーザー、API、コンテナ、Pod) の数に起因しています。認証について語るときは、まずどのコンポーネントが関係しているかを明確にしなければなりません。Kubernetes クラスタに対して認証を行っていますか？または、環境内の別のマイクロサービスにアクセスしようとしているマイクロサービスが関係していますか？Kubernetes クラスタの外部にあるクラウドリソースが関係していますか？あるいは、エンドポイント (クラウドリソース、システム、または人) が、クラスタで実行されているアプリケーションの 1 つにアクセスしてそれを使用しようとしていますか？

OAuth 2.0 と OIDC による認証と認可

ユーザーがエンドポイントにアクセスしようとしているとします。ユーザーには次の種類があります。

• 実際の人間
• 人間以外のアカウント (アプリケーション Pod、システムコンポーネント、ソフトウェアパイプライン、物理または論理エンティティ)

エンドポイントには次の種類があります。

• API
• ソフトウェアの一部 (データベースなど)
• 物理サーバーまたは仮想サーバー

エンドポイントがユーザーからリクエストを受信したとき、エンドポイントは以下を理解できる必要があります。

• 要求の送信元 (認証部分)
• そのユーザーが許可されている操作 (認可部分)

Kubernetes の公式ドキュメントには、認証に関するセクションがあります。この公式ドキュメントの主なポイントは、Kubernetes における認証とは Kubernetes API サーバーに対して行われた API リクエストを認証するプロセスを指しているということです。そのような要求は、ターミナルや GUI で、または API 呼び出しを介して kubectl または oc コマンドから行うことができますが、最終的にはすべてが API サーバーに送信されます。

利用可能な認証テクノロジーとプロトコル (LDAP、SAML、Kerberos など) は多数ありますが、最も成功している一般的な API 認証方法は、OAuth 2.0 と OpenID Connect (OIDC) の組み合わせです。

OAuth 2.0 は一連のリソース (リモート API やユーザーデータなど) へのアクセスを許可するように設計された認可プロトコル (認証プロトコルではない) です。これを実現するために、OAuth 2.0 はアクセストークンを使用します。これは、エンドユーザーに代わってリソースにアクセスするための認可を表すデータです。

OpenID Connect (OIDC) は、OAuth 2.0 フレームワークに ID レイヤーを追加して拡張する認証プロトコルです。名前や E メールアドレスといった特定のユーザー情報を要求するためのメカニズムを提供し、ユーザーがこの情報へのアクセスを許可または拒否できるようにします。OAuth2 のプロトコルの主な拡張は、アクセストークンとともに返される ID トークンと呼ばれる追加フィールドです。このトークンは、サーバーによって署名された、ユーザーの E メールなどの特定のフィールドを持つ JSON Web Token (JWT) です。

以下の図は、ユーザーが kubectl コマンドを使用して Kubernetes クラスタで一連のアクションを設定しようとする場合に実行される手順を示しています。完全なプロセスはさらに複雑ですが、公式ドキュメントに詳しく記載されています。

キャプション：認証プロセスを示す Kubernetes ドキュメントのフローチャート

1. まず、ID プロバイダーにログインします
2. ID プロバイダーは、access_token、id_token、および refresh_token を提供します
3. kubectl を使用して、id_token と --token パラメーターを使用するか、トークンを kubeconfig に追加します
4. kubectl は、id_token を「Authorization」という名前のヘッダーに入れて API サーバーに送信します
5. API サーバーは、JWT 署名が有効であること、id_token の有効期限が切れていないこと、およびユーザーがこのトランザクションに対して認可されていることを検証します
6. API サーバーが応答を kubectl に返し、これによってフィードバックが提供されます

id_token には ID を検証するために必要なすべてのデータが含まれているため、Kubernetes は ID プロバイダーとこれ以上やり取りする必要はありません。これは、特に各要求がステートレスである場合に、認証に対して非常にスケーラブルなソリューションとなります。

ロールベースのアクセス制御 (RBAC) とは

ロールベースのアクセス制御 (RBAC) とは、組織内の個々のユーザーのロールに基づいて、コンピュータやネットワークリソースへのアクセスを調整する方法です。たとえば、プラットフォームのシステム管理者は、環境全体に変更を加える権限を持っていることがあります (クラスタ上のすべてのアプリケーションに影響を与える可能性があります)。しかし、クラスタ上の 1 つのアプリケーションのみを担当している管理者は、おそらくそのアプリケーションに対する変更のみが許可されています。

以下の図に、これら 2 人のユーザーの例を示します。緑のアイコンは HR チームに所属するユーザーを示しています。黒のアイコンはプラットフォーム管理者です。HR ユーザーは HR アプリグループのリソースにしかアクセスできませんが、プラットフォーム管理者はプラットフォーム内のすべてにアクセスできます。

HR ユーザーには認可ステップで緑のトークンが付与され、管理者には黒のトークンが付与されます。エンドポイント (Kubernetes クラスタまたは OpenShift API) とのインタラクションの一環として、各ユーザーはトークン (緑または黒) を要求に追加します。このトークンに基づいて、クラスタは各ユーザーがアクセスできるアプリケーションを認識します。

トランスポート層とエンドポイント

Kubernetes エンドポイントに到達するための最も一般的な転送メカニズムは、HTTPS 用の暗号化トンネルを提供するトランスポート層セキュリティ (TLS) です。

Linux または Windows 仮想マシンのシステム管理者であれば、これらのエンドポイントへのアクセスにはおそらく SSH または RDP を使用します。これらのプロトコルは、ユーザーとエンドポイント (Linux または Windows サーバー) の間のトラフィックを暗号化します。同様に、API、ソフトウェア、またはサードパーティの SaaS (Software-as-a-Service) を扱う場合、最も一般的な転送メカニズムは TLS です。

エンドポイントとユーザーの両方の間に安全で暗号化されたセッションを確立する方法はこのブログでは説明しませんが、これはエンドポイント (ユーザーまたはエンドポイントのいずれか、またはこの両方) の認証に使用されるトンネルとキー (または証明書) に依存し、エンドポイント間で送信されるパケットを暗号化/復号化します。

Kubernetes および OpenShift アクセスのレイヤー

認証、認可、転送の 3 つの概念は、一度理解してしまえば比較的簡単なものです。しかし、どの IT 環境にも考慮すべき複数のレイヤーがあり、複雑さと混乱の多くはここで発生します。

Kubernetes のアーキテクチャには、次の 3 つの主要なレイヤーがあります。

• インフラストラクチャ・レイヤー：コンピュート、ストレージ、ネットワーク。このレイヤーは、パブリッククラウド、オンプレミス、またはコロケーション・データセンターであるか、これらすべてが混在したものです。
• Kubernetes レイヤー：すべてのコンテナ化アプリケーションのホスティングと管理を担います。
• コンテナ化アプリケーション：特定のアプリケーションを形成するコンテナのグループ。これらのアプリケーションには、市販のアプリケーション (COTS)、独立系ソフトウェアベンダー (ISV)、自社開発のアプリケーション、またはこれらの組み合わせが含まれます。

各レイヤーは、認証と認可の両方の機能を提供し、必要とします。

インフラストラクチャ・レイヤーでの認証と認可

インフラストラクチャ・レイヤーのユーザーは通常、特定のコンポーネント (ストレージ、ネットワーク、コンピューティング、または仮想化のいずれか) へのアクセスを必要とするシステム管理者です。このレイヤー (上図では最下段の黒のレイヤー) にアクセスするために、管理者ユーザーは通常、ストレージ、ネットワーク、またはコンピュートノード (iLO や iDRAC など) への専用のインタフェースを使用して、SSH 経由でサーバーに接続します。認証メカニズムは、RADIUS/TACACS (ネットワーク)、LDAP または Kerberos (サーバーとストレージ)、またはその他のドメイン固有の認証メカニズムを組み合わせることができます。

興味深いことに、同じインフラストラクチャ管理ユーザーが、OpenShift (青のレイヤー) でホストされたアプリケーション (黒のレイヤー) を使用して、アクティビティの実行を支援している場合があります。

たとえばネットワーク管理スタックは、OpenShift で実行されるコンテナ化アプリケーションである場合があります。しかしこのコンテキストでは、管理者ユーザーは機能的にはアプリケーション (この例ではネットワーク管理スタック) へのアクセスを試みる通常の (緑の) ユーザーです。このレイヤーでは、認証メカニズムと認可メカニズムが異なります。たとえば、アプリケーションへの接続は TLS/SSL 接続を介して行われる場合があり、ネットワーク管理スタックコンソールにアクセスするための認証情報が必要になる場合があります。

OpenShift の認証と認可

上のレイヤーには青いレイヤー (一般に OpenShift または Kubernetes とやり取りするレイヤー) があり、ここでは Kubernetes API サーバーと通信します。これは人間にも人間ではないユーザーにも当てはまります。使用しているのが GUI コンソールかターミナルかは問いません。最終的に、OpenShift または Kubernetes とのすべてのインタラクションが API サーバーを経由します。

OAuth2 と OIDC の組み合わせは API の認証と認可に極めて適しているため、OpenShift には OAuth2 サーバーが組み込まれています。この OAuth2 サーバーの設定の一部として、サポートされている ID プロバイダーを追加する必要があります。ID プロバイダーは、OAuth2 サーバーによるユーザーの確認を支援します。この部分が設定されると、OpenShift でユーザーを認証する準備が整います。

認証されたユーザーの場合、OpenShift はアクセストークンを作成し、そのトークンをユーザーに返します。このトークンは OAuth アクセストークンと呼ばれます。ユーザーはこれらの OAuth アクセストークンを、有効期限が切れるまで、または無効になるまで、OpenShift API との各インタラクション時に使用できます。

ユーザーとサービスアカウント

ユーザーは、人間の場合も、人間ではない場合もあります。OpenShift には概念的に異なるロールがあり、それぞれ任意のユーザーが担う可能性があります。

• 一般ユーザー：Kubernetes クラスタとのインタラクションを行う人間
• システムユーザー：人間 (プラットフォーム管理者など) と人間以外のクラスタコンポーネント (レジストリ、さまざまなコントロールプレーン・ノード、アプリケーションノードなど)
• その他の人間以外のユーザー：これにはサービスアカウントが含まれます。これは通常、Kubernetes API とのインタラクションを必要とするアプリケーション (クラスタ内外) を表します。たとえば、GitLab、GitHub、Tekton を使用するパイプラインは、OpenShift とやり取りするためにサービスアカウントを使用します。

OpenShift では、ユーザーとサービスアカウントはグループに編成できます。グループは、複数のユーザーに一度に権限を付与する認可ポリシーを管理する際に便利です。たとえば、プロジェクト内のオブジェクトへのアクセス権を各ユーザーに個別に付与する代わりに、グループに許可することができます。

ユーザーは 1 つまたは複数のグループに割り当てることができ、各グループは特定のユーザーセットを表します。ほとんどの組織には、すでにユーザーグループがあります (Active Directory サーバー内など)。内部 OpenShift グループレコードと LDAP レコードを同期することが可能です。

ロールベースのアクセス制御 (RBAC) と認可

ユーザーが正常に認証され、OAuth2 アクセストークンを受信すると、そのユーザーには RBAC に基づいた一連のアクセス特権が付与されます。RBAC オブジェクトは、ユーザーがリソースに対して所定のアクションを実行できるかどうかを決定します。RBAC の定義は、クラスタ全体またはプロジェクト全体に適用することができます。

RBAC は以下を使用して管理されます。

• ルール：一連のオブジェクトに対する許可された動作のセット。これらを総称して CRUD (作成、読み取り、更新、削除) と言います。これらは永続ストレージの基本的な操作です。RESTful API のコンテキストでは、これらは HTTP プロトコルの POST、GET、PUT または PATCH、および DELETE に対応します。たとえば、ユーザーまたはサービスアカウントに、Pod の作成が許可されている場合があります。
• ロール：ルールの集合。ユーザーとグループを複数のロールに関連付け (バインド) できます。
• バインディング：ロールによるユーザーとグループ間の関連付け

OpenShift は、事前定義されたロール (クラスタ管理者、基本ユーザー、その他) を提供します。以下の図は、ルール、ロール、バインディングを使用する RBAC の概要を示しています (OpenShift ドキュメントから抜粋)。

OpenShift レイヤー内のリソースからの認証と認可

Kubernetes レイヤー内のリソース (通常は Pod) は、次のアクションの 1 つを実行するためにアクセス権を要求できます。

• Kubernetes API とのインタラクション
• リソースがホストされているホスト (インフラストラクチャ・レイヤー) とのインタラクション
• クラスタ外のリソース (クラウドリソースなど) とのインタラクション

Kubernetes API とのインタラクション

Kubernetes API とのインタラクションには、OAuth を使用した何らかの認証が必要です。Pod は人間以外のユーザーを表すため、API サーバーとやり取りするためにはサービスアカウントが必要です。

デフォルトで、Pod はサービスアカウントに関連付けられています。そのサービスアカウントの認証情報 (トークン) は、その Pod 内の各コンテナのファイルシステム (/var/run/secrets/kubernetes.io/serviceaccount/token) に配置されます。このモデルが優れたアイデアかどうかについては議論がありますが、これは OpenShift で設定可能であり、ACS などのツールでポリシーを使用して適用できます。

ホスト/Kubernetes インフラストラクチャ・レイヤーとのインタラクション

このタイプのインタラクションは Kubernetes API 呼び出しに依存しません。基盤ホストのプロセスレベルの権限管理 (Linux レベルの権限) に関連しています。

基盤となるインフラストラクチャで Pod が実行できるアクション (権限) と、Pod がアクセスできるリソースのマッピングは、セキュリティ・コンテキストによる制約 (SCC) を使用して実行されます。SCC は、Pod をリソースグループに制限する OpenShift リソースであり、Kubernetes セキュリティ・コンテキスト・リソースに似ています。

たとえば、プロセスは特定のパスにファイルを作成する権限を持っている、または持っていない場合があり、既存のファイルへの書き込み権限を持っていない (読み取り権限のみ持っている) 場合があります。両方の主な目的は、ホスト環境に対する Pod のアクセスを制限することです。ロールベースのアクセス制御を使用してユーザー特権を管理するのと同様に、SCC を使用して Pod の権限を制御できます。

外部リソースとのインタラクション

Pod がクラスタ外のリソースにアクセスしなければならないことがあります。たとえば、データやログファイルのオブジェクトストア (S3 バケットなど) へのアクセスが必要になる場合があります。これには、リソースがユーザーを認証する方法と、そのリソースと通信する Pod に何を組み込む必要があるかを理解する必要があります。

サービスアカウントのロールに対する Amazon の ID 管理とアクセス管理 (IAM) (IRSA) は、AWS 上のサービスにアクセスするための認証情報のセットを Pod に提供する設計の一例です。Pod が作成されると、Webhook が、サービスアカウントを参照する Pod に変数 (Kubernetes サービスアカウント・トークンへのパスと、引き受けたロールの ARN) を挿入します。これは、「ミューテーション」とも呼ばれます。IAM が引き受けたロールが、必要な AWS 権限を持っている場合、Pod は一時的な STS 認証情報を使用して AWS SDK 操作を実行できます。

OpenShift 内のコンテナ化アプリケーションの認証と認可

最後のレイヤーは、コンテナ化アプリケーションです。前のレイヤーと同様に、各コンテナは以下へのアクセスを試みることができます。

• Kubernetes API
• クラスタ内の別のコンテナまたはクラスタ外のリソースによって提供される別の API
• 非 API 接続 (データベースアクセスのために特定のポートに接続するなど) 

上図に示すように、API にアクセスするコンテナは次のことを実行できます。

• アプリケーションに関連付けられた認証情報を使用して別の API に直接アクセスする (Kubernetes Secret を使用するなど)
• エンドポイントでサポートされている認証メカニズムを使用して、非 API エンドポイントに直接アクセスする
• Pod サービスアカウントを使用する

API の直接呼び出し

コンテナは、KUBERNETES_SERVICE_HOST およびKUBERNETES_SERVICE_PORT_HTTPS 環境変数を取得することで、Kubernetes API にアクセスできます。非 Kubernetes API トラフィックの場合、アプリケーションはクライアントライブラリ (AWS API など) または開発者が作成するカスタム統合のいずれかを使用します。

非 API ベースの通信

アプリケーションは、データの取得またはプッシュのためにデータベースに接続することが必要な場合があります。この場合、認証は通常、コンテナ内のコードの一部として処理され、通常は環境変数、シークレット、ConfigMap などを使用してランタイム時に更新できます。

サービスアカウントの使用

Kubernetes API サーバーに対して認証するために推奨される方法は、サービスアカウント認証情報を使用することです。ほとんどのコーディング言語には、サポートされている Kubernetes クライアントライブラリのセットがあります。これらのライブラリに基づいて、API サーバーとの通信に Pod のサービスアカウント認証情報が使用されます。OpenShift は、各 Pod 内にサービスアカウントを自動的にマウントして、スコープトークンにアクセスできるようにします。

非 Kubernetes API 呼び出しの場合、コンテナは、外部 API サービスに対して認証する際に Pod サービスアカウントを使用することもできます。

認証と認可

コンピュータは、ユーザーが誰であり、そのユーザーがどのような動作が許可されているかを知る必要があります。これが認証と認可の領域であり、ここでは Kubernetes と OpenShift でどのように管理されるかについて説明しました。

この記事を詳細にレビューし、フィードバックを寄せていただいた Shane Boulden 氏と Derek Waters 氏に感謝いたします。