IAP による GKE アプリとリソースの保護

このページでは、Identity-Aware Proxy（IAP）を使用して Google Kubernetes Engine（GKE）インスタンスを保護する方法について説明します。

Google Cloud 上にないリソースを保護するには、オンプレミスのアプリとリソースの保護をご覧ください。

概要

IAP は GKE の Ingress によって統合されます。これにより、VPN ではなく、リソースレベルで従業員によるアクセスを制御できます。

GKE クラスタで、受信トラフィックは Cloud Load Balancing のコンポーネントである HTTP(S) 負荷分散によって処理されます。HTTP(S) ロードバランサは通常、Kubernetes Ingress コントローラによって構成されます。Ingress コントローラは、Kubernetes Ingress オブジェクトから構成情報を取得します。このオブジェクトは、1 つ以上の Service オブジェクトに関連付けられています。Service オブジェクトは、受信リクエストを特定の Pod とポートに転送するために使用するルーティング情報を保持します。

Kubernetes バージョン 1.10.5-gke.3 以降では、サービスと BackendConfig オブジェクトを関連付けることで、ロードバランサの構成を追加できます。BackendConfig は、kubernetes/ingress-gce リポジトリに定義されるカスタム リソース定義（CRD）です。

Kubernetes Ingress コントローラは、BackendConfig から構成情報を読み取り、それに従ってロードバランサを設定します。BackendConfig は、Cloud Load Balancing に固有の構成情報を保持しています。これにより、HTTP(S) バックエンド サービスごとに個別の構成を定義できます。

始める前に

GKE で IAP を有効にするには、次のものが必要です。

  • 課金が有効になっている Google Cloud Console プロジェクト。
  • HTTPS ロードバランサで処理される 1 つ以上の GKE インスタンスを含むグループ。GKE クラスタに Ingress オブジェクトを作成すると、ロードバランサが自動的に作成されます。
  • ロードバランサのアドレスに登録されたドメイン名。
  • すべてのリクエストに ID があることを確認するアプリコード。

IAP の有効化

プロジェクトの OAuth 同意画面をまだ構成していない場合は、画面を構成するように指示されます。OAuth 同意画面を構成する方法については、OAuth 同意画面の設定をご覧ください。

IAP アクセス権の設定

  1. [Identity-Aware Proxy] ページに移動します。
    [Identity-Aware Proxy] ページに移動
  2. IAP で保護するプロジェクトを選択します。

  3. アクセスを許可するリソースの横にあるチェックボックスをオンにします。

    リソースが表示されない場合は、リソースが作成され、BackendConfig Compute Engine Ingress コントローラが同期されていることを確認します。

    バックエンド サービスが利用可能であることを確認するには、次の gcloud コマンドを実行します。

    gcloud compute backend-services list
  4. 右側のパネルで [プリンシパルを追加] をクリックします。
  5. 表示される [メンバーの追加] ダイアログで、プロジェクトに対する IAP で保護されたウェブアプリ ユーザーの役割を付与するグループ、または個人のメールアドレスを追加します。

    このロールを持つことができるプリンシパルの種類は次のとおりです。

    • Google アカウント: user@gmail.com
    • Google グループ: admins@googlegroups.com
    • サービス アカウント: server@example。gserviceaccount.com
    • Google Workspace ドメイン: example.com

    追加する Google アカウントは、自分がアクセスできるものにしてください。

  6. [役割] のプルダウン リストから [Cloud IAP] > [IAP で保護されたウェブアプリ ユーザー] を選択します。
  7. [保存] をクリックします。

BackendConfig の構成

IAP に BackendConfig を構成するには、Kubernetes Secret を作成し、iap ブロックを BackendConfig に追加します。

Kubernetes Secret の作成

BackendConfig は Kubernetes Secret を使用して、以前作成した OAuth クライアントをラップします。Kubernetes Secret は、kubectl コマンドライン インターフェース（CLI）を使用して他の Kubernetes オブジェクトと同様に管理されます。Secret を作成するには、次のコマンドを実行します。client_id_key と client_secret_key は、OAuth 認証情報の作成時にダウンロードした JSON ファイルのキーです。

kubectl create secret generic my-secret --from-literal=client_id=client_id_key \
    --from-literal=client_secret=client_secret_key

Secret が正常に作成されると、上記のコマンドが確認用の出力を表示します。

secret "my-secret" created

BackendConfig への iap ブロックの追加

IAP に BackendConfig を構成するには、enabled と secretName の値を指定する必要があります。これらの値を指定するには、compute.backendServices.update 権限が付与されていることを確認して、BackendConfig に iap ブロックを追加します。このブロックでは、my-secret は以前に作成した Kubernetes Secret の名前です。

GKE バージョン 1.16.8-gke.3 以降では、cloud.google.com/v1 API バージョンを使用します。以前の GKE バージョンを使用している場合は、cloud.google.com/v1beta1 を使用してください。

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: config-default
  namespace: my-namespace
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

また、サービスポートを BackendConfig に関連付けて、IAP の有効化をトリガーする必要があります。たとえば、次のアノテーションを Service リソースに追加し、サービスのすべてのポートをデフォルトで BackendConfig にします。

metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"default": "config-default"}'

構成のテストを行うには、kubectl get event を実行します。「no BackendConfig for service port exists」というメッセージが表示された場合、サービスポートと BackendConfig は正常に関連付けられていますが、BackendConfig リソースが見つかりません。このエラーが発生するのは、BackendConfig リソースが作成されていない場合、誤った名前空間に作成された場合、または Service アノテーションの参照にスペルミスがあった場合です。

参照先の secretName が存在しないか、正しく構成されていないと、次のいずれかのエラー メッセージが表示されます。

  • BackendConfig default/config-default is not valid: error retrieving secret "foo": secrets "foo" not found. このエラーを解決するには、前のセクションで説明したとおり Kubernetes Secret が正しく作成されていることを確認します。
  • BackendConfig default/config-default is not valid: secret "foo" missing client_secret data. このエラーを解決するには、OAuth 認証情報が正しく作成されていることを確認します。また、前述の手順でダウンロードした JSON の正しい client_id キーと client_secret キーを参照していることも確認します。

たとえば、enabled フラグが true に設定され、secretName が正しく設定されている場合、選択したリソースに IAP が構成されています。

IAP の無効化

IAP を無効にするには、BackendConfig で enabled を false に設定する必要があります。BackendConfig から IAP ブロックを削除しても、設定が維持されます。たとえば、IAP で secretName: my_secret が有効になっているときにブロックを削除しても、IAP では、my_secret に保存されている OAuth 認証情報が有効になります。

次のステップ