バージョン 1.6。このバージョンは、Anthos バージョンのサポート ポリシーに記載されているとおりにサポートされており、ベアメタル版 Anthos クラスタに影響するセキュリティの脆弱性、漏えい、問題に対する最新のパッチとアップデートが提供されます。詳細については、リリースノートをご覧ください。これは最新バージョンではありません。

ベアメタル版 Anthos クラスタでの OIDC による ID 管理

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 Console UI を使用した OIDC 認証。ユーザーは Kubernetes クラスタページから直接クラスタにログインします。この方法では、クラスタを Google Cloud に登録する必要があります。クラスタは、ベアメタル版 Anthos クラスタに自動的に登録されます。

OIDC はヘッドレス ワークフローをサポートしていません。OIDC でブラウザベースの認証を行う場合は、ID プロバイダのウェブページにリダイレクトし、ユーザーに同意とアカウントのログイン情報(パスワード)を求める必要があります。

OIDC と Kubernetes のアクセス制御

多くの場合、OIDC 認証は Kubernetes のロールベースのアクセス制御(RBAC)と組み合わせて使用されています。RBAC では、詳細な認可ポリシーを作成して、特定のクラスタ リソースに対して特定の操作を実行できるユーザーまたはグループを定義できます。

OIDC 認証の概要

OIDC 認証の一般的な手順は次のとおりです。

  1. ユーザーがユーザー名とパスワードを入力して OpenID プロバイダにログインします。
  2. OpenID プロバイダがユーザーの ID トークンを発行します。

  3. トークンはプロバイダによって署名され、事前構成されたコールバック URL を介して返されます。

  4. アプリケーションがユーザーに代わって動作し、Kubernetes API サーバーに HTTPS リクエストを送信します。アプリケーションは、リクエスト ヘッダーにユーザーの ID トークンを含めます。

  5. Kubernetes API サーバーがプロバイダの証明書を使用して ID トークンを確認します。トークンを解析してユーザー ID とユーザーのグループ(存在する場合)を学習します。

通常、OIDC の設定と認証には、次の 3 つのペルソナが関係します。

  • 組織管理者。OpenID プロバイダを選択し、クライアント アプリケーションをプロバイダに登録します。

  • プラットフォーム管理者。クラスタを使用するユーザーのために 1 つ以上のクラスタと認証構成ファイルを作成します。

  • オペレーターまたはデベロッパー。1 つ以上のクラスタでワークロードを実行し、OIDC を使用して認証します。

任意の OpenID プロバイダを使用できます(プロバイダは OpenID Foundation によって認定されています)。具体的な登録プロセスはプロバイダによって異なりますが、一般的な手順は次のとおりです。

  1. プロバイダの発行者 URI を確認します。gcloud CLI または Google Cloud Console は、ここに認証リクエストを送信します。

  2. プロバイダに gcloud CLI と Cloud Console のリダイレクト URL を提供します。

  3. クライアント ID とクライアント シークレットを設定します。gcloud CLI と Cloud Console は、このクライアント ID / シークレットを使用して OpenID プロバイダを認証します。

  4. セキュリティ グループのカスタム スコープとクレームを設定します。一般に、ポリシーの安定性と監査性を高めるため、ユーザーではなくグループに基づいてクラスタの RBAC ポリシーを定義する必要があります。適切なスコープが要求されている場合、ほとんどの OIDC プロバイダは ID トークンにグループ クレームを含めます。特定のグループのクレームとスコープは OIDC プロバイダによって異なるため、これらのプロバイダ固有のスコープやクレームを設定する際にカスタマイズが必要になります。

通常、新しいベアメタル版 Anthos クラスタをインストールする前に、プラットフォーム管理者が組織管理者から OIDC 構成を取得し、関連する OIDC フィールドをクラスタ構成で構成します。

クラスタのインストールが完了したら、プラットフォーム管理者が認証構成ファイルを取得し、それを CLI ユーザーと共有します。通常、プラットフォーム管理者は、安全なホスト上にファイルをホストするか、内部ツールを使用して各ユーザーのマシンに構成ファイルを push して認証構成を共有します。次に、CLI ユーザーが共有構成ファイルを使用して新しいクラスタを認証します。

プラットフォーム管理者は、複数のクラスタに対する認証構成の詳細を 1 つの認証構成ファイルに保存することもできます。

Cloud Console の場合、このような構成ファイルは必要ありません。ユーザーは Cloud Console にアクセスするときに、クラスタに構成された Authenticate with the Identity Provider を選択し、[Login.] をクリックします。