OpenID Connect（OIDC）を使用して、ベアメタル版 Anthos クラスタで認証を行うことができます。OIDC は OAuth 2.0 を基に構築された認証レイヤで、RESTful HTTP API を指定し、データ形式として JSON を使用します。
OIDC では、既存の ID プロバイダを使用して、ベアメタル版 Anthos クラスタでのユーザーとグループの認証を管理できます。OIDC を使用すると、ベアメタル版 Anthos クラスタへのアクセスを管理できます。組織内では、アカウントの作成、有効化、無効化に関する標準的な手順が使用できます。また、組織のセキュリティ グループを使用して、クラスタまたはクラスタ内の特定のサービスへのアクセスを構成することもできます。マネージド アクセスは、管理者、ユーザー、ハイブリッド、スタンドアロンなど、すべてのベアメタル版 Anthos クラスタで機能します。
ベアメタル版 Anthos はクラスタは、オンプレミスと公開アクセス可能な ID プロバイダの両方をサポートしています。たとえば、オンプレミスで Active Directory フェデレーション サービス コンポーネントを使用し、Google または Okta からアクセス可能な ID プロバイダ サービスを使用することもできます。また、ID プロバイダの証明書は有名なパブリック認証局（CA）またはプライベート CA によって発行されます。
ユーザーは 2 つの OIDC 認証方法を使用できます。
コマンドライン インターフェース（CLI）による OIDC 認証。ユーザーは、gcloud コマンドを実行して、ブラウザベースのログイン / 同意ページで認証を行います。
Google Cloud コンソール UI を使用した OIDC 認証。ユーザーは、Kubernetes クラスタページから直接クラスタにログインします。この方法では、クラスタを Google Cloud に登録する必要があります。クラスタは、ベアメタル版 Anthos クラスタに自動的に登録されます。
OIDC はヘッドレス ワークフローをサポートしていません。OIDC でブラウザベースの認証を行う場合は、ID プロバイダのウェブページにリダイレクトし、ユーザーに同意とアカウントのログイン情報（パスワード）を求める必要があります。
OIDC と Kubernetes のアクセス制御
多くの場合、OIDC 認証は Kubernetes のロールベースのアクセス制御（RBAC）と組み合わせて使用されています。RBAC では、詳細な認可ポリシーを作成して、特定のクラスタ リソースに対して特定の操作を実行できるユーザーまたはグループを定義できます。
OIDC 認証の概要
OIDC 認証の一般的な手順は次のとおりです。
- ユーザーがユーザー名とパスワードを入力して OpenID プロバイダにログインします。
OpenID プロバイダがユーザーの ID トークンを発行します。
トークンはプロバイダによって署名され、事前構成されたコールバック URL を介して返されます。
アプリケーションがユーザーに代わって動作し、Kubernetes API サーバーに HTTPS リクエストを送信します。アプリケーションは、リクエスト ヘッダーにユーザーの ID トークンを含めます。
Kubernetes API サーバーがプロバイダの証明書を使用して ID トークンを確認します。トークンを解析してユーザー ID とユーザーのグループ（存在する場合）を学習します。
通常、OIDC の設定と認証には、次の 3 つのペルソナが関係します。
組織管理者。OpenID プロバイダを選択し、クライアント アプリケーションをプロバイダに登録します。
プラットフォーム管理者。クラスタを使用するユーザーのために 1 つ以上のクラスタと認証構成ファイルを作成します。
オペレーターまたはデベロッパー。1 つ以上のクラスタでワークロードを実行し、OIDC を使用して認証します。
任意の OpenID プロバイダを使用できます（プロバイダは OpenID Foundation によって認定されています）。具体的な登録プロセスはプロバイダによって異なりますが、一般的な手順は次のとおりです。
プロバイダの発行者 URI を確認します。gcloud CLI または Google Cloud Console は、ここに認証リクエストを送信します。
プロバイダに gcloud CLI と Google Cloud コンソールのリダイレクト URL を提供します。
クライアント ID とクライアント シークレットを設定します。gcloud CLI と Google Cloud コンソールは、このクライアント ID / シークレットを使用して OpenID プロバイダを認証します。
セキュリティ グループのカスタム スコープとクレームを設定します。一般に、ポリシーの安定性と監査性を高めるため、ユーザーではなくグループに基づいてクラスタの RBAC ポリシーを定義する必要があります。適切なスコープが要求されている場合、ほとんどの OIDC プロバイダは ID トークンにグループ クレームを含めます。特定のグループのクレームとスコープは OIDC プロバイダによって異なるため、これらのプロバイダ固有のスコープやクレームを設定する際にカスタマイズが必要になります。
通常、新しいベアメタル版 Anthos クラスタをインストールする前に、プラットフォーム管理者が組織管理者から OIDC 構成を取得し、関連する OIDC フィールドをクラスタ構成で構成します。
クラスタのインストールが完了したら、プラットフォーム管理者が認証構成ファイルを取得し、それを CLI ユーザーと共有します。通常、プラットフォーム管理者は、安全なホスト上にファイルをホストするか、内部ツールを使用して各ユーザーのマシンに構成ファイルを push して認証構成を共有します。次に、CLI ユーザーが共有構成ファイルを使用して新しいクラスタを認証します。
プラットフォーム管理者は、複数のクラスタに対する認証構成の詳細を 1 つの認証構成ファイルに保存することもできます。
Google Cloud コンソールの場合、このような構成ファイルは必要ありません。ユーザーは Google Cloud コンソールにアクセスするときに、クラスタに構成された Authenticate
with the Identity Provider を選択し、[Login.] をクリックします。