GKE での IAP の有効化

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

概要

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

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

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 同意画面を構成していない場合は、画面を構成する必要があります。この画面では、メールアドレスとプロダクト名が必要です。

  1. OAuth 同意画面に移動します。
    同意画面を構成
  2. [サポートメール] で、一般公開される連絡先として表示するメールアドレスを選択します。このメールアドレスは、自分のメールアドレスまたは自身が所有する Google グループにする必要があります。
  3. [アプリケーション名] に、アプリケーションの表示名を入力します。
  4. 任意の詳細を追加します。
  5. [保存] をクリックします。

プロダクト名やメールアドレスなど、OAuth 同意画面の情報を後で変更する場合は、上記の手順を繰り返して同意画面を構成します。

OAuth 認証情報の作成

  1. [認証情報] ページに移動します。
    [認証情報] ページに移動
  2. [認証情報の作成] プルダウン リストを開き、[OAuth クライアント ID] を選択します。
  3. [アプリケーションの種類] で、[ウェブ アプリケーション] を選択します。
  4. OAuth クライアント ID の名前を追加します。
  5. [作成] をクリックします。OAuth クライアント ID とクライアント シークレットが生成され、OAuth クライアント ウィンドウに表示されます。
  6. [OK] をクリックします。
  7. 作成したクライアントを選択します。
  8. クライアント ID をクリップボードにコピーします。
  9. [承認済みのリダイレクト URI] フィールドに次の形式でユニバーサル リダイレクト URL を追加します。
    https://iap.googleapis.com/v1/oauth/clientIds/CLIENT_ID:handleRedirect

    ここで、CLIENT_ID は OAuth クライアント ID です。

  10. ページの上部にある [JSON をダウンロード] をクリックします。この認証情報は後で使用します。

IAP アクセス権の設定

  1. [Identity-Aware Proxy] ページに移動します。
    [Identity-Aware Proxy] ページに移動
  2. IAP で保護するプロジェクトを選択します。
  3. メンバーを追加するリソースの横にあるチェックボックスをオンにします。
  4. 右側のパネルで [メンバーを追加] をクリックします。
  5. 表示される [メンバーの追加] ダイアログで、プロジェクトに対する IAP で保護されたウェブアプリ ユーザーの役割を付与するグループ、または個人のメールアドレスを追加します。

    メンバーにすることができるアカウントの種類は以下のとおりです。

    • Google アカウント: user@gmail.com
    • Google グループ: admins@googlegroups.com
    • サービス アカウント: server@example.gserviceaccount.com
    • G Suite のドメイン: 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_keyclient_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 を構成するには、enabledsecretName の値を指定する必要があります。これらの値を指定するには、compute.backendServices.update 権限が付与されていることを確認して、BackendConfig に iap ブロックを追加します。このブロックで、my-secret は上記で作成した Kubernetes Secret の名前です。

apiVersion: cloud.google.com/v1beta1
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 で enabledfalse に設定する必要があります。BackendConfig から IAP ブロックを削除しても、設定が維持されます。たとえば、IAP で secretName: my_secret が有効になっているときにブロックを削除しても、IAP では、my_secret に保存されている OAuth 認証情報が有効になります。

次のステップ