このページでは、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 オブジェクトは、受信リクエストを特定の 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 オブジェクトを作成すると、ロードバランサが自動的に作成されます。
- HTTPS の Ingress の作成をご覧ください。
- ロードバランサのアドレスに登録されたドメイン名。
- すべてのリクエストに ID があることを確認するアプリコード。
- ユーザーの ID の取得をご覧ください。
IAP の有効化
プロジェクトの OAuth 同意画面をまだ構成していない場合は、画面を構成するように指示されます。OAuth 同意画面を構成する方法については、OAuth 同意画面の設定をご覧ください。
IAP アクセス権の設定
-
[Identity-Aware Proxy] ページに移動します。
[Identity-Aware Proxy] ページに移動 - IAP で保護するプロジェクトを選択します。
-
アクセスを許可するリソースの横にあるチェックボックスをオンにします。
リソースが表示されない場合は、リソースが作成され、BackendConfig Compute Engine Ingress コントローラが同期されていることを確認してください。
バックエンド サービスが利用可能であることを確認するには、次の gcloud コマンドを実行します。
gcloud compute backend-services list
- 右側のパネルで [プリンシパルを追加] をクリックします。
-
表示される [メンバーの追加] ダイアログで、プロジェクトに対する IAP で保護されたウェブアプリ ユーザーの役割を付与するグループ、または個人のメールアドレスを追加します。
このロールを持つことができるプリンシパルの種類は次のとおりです。
- Google アカウント: user@gmail.com
- Google グループ: admins@googlegroups.com
- サービス アカウント: server@example.gserviceaccount.com
- Google Workspace ドメイン: example.com
追加する Google アカウントは、自分がアクセスできるものにしてください。
- [役割] のプルダウン リストから [Cloud IAP] > [IAP で保護されたウェブアプリ ユーザー] を選択します。
- [保存] をクリックします。
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 認証情報が有効になります。