ログインを確認する

GDC コンソールまたは gdcloud CLI でログインできることを確認します。

ログイン

Distributed Cloud にログインするには、次の手順を行います。

コンソール

次の URL を新しいブラウザタブで開いて、Distributed Cloud UI にアクセスします。

https://GDC_URL

GDC_URL は、ドメイン ネーム システム（DNS）サービスを構成したインフラストラクチャ オペレーター（IO）のドメイン名に置き換えます。

URL を初めて開くと、ID プロバイダのログインページにリダイレクトされます。ログインするには、以前に作成したユーザー名とパスワードを使用します。

注: https://GDC_URL/racks などの Kubernetes リソースに依存するページは機能しません。Chrome デバッグ コンソールにレスポンスの forbidden エラーが表示されます。このエラーは、テストユーザーに権限が付与されておらず、ロールにバインドされていないために発生します。

CLI

gdcloud CLI にログインするときは、gdcloud auth login コマンドを使用して、gdcloud CLI に対するプリンシパルを認証します。gdcloud CLI は、そのプリンシパルを使用して、 Google Cloud のリソースとサービスを管理するための認証と認可を行います。

ログインする前に、次のことを確認してください。

• gdcloud CLI バイナリをダウンロードして、システムにインストールします。詳細については、gdcloud CLI をダウンロードするをご覧ください。
• gdcloud CLI のデフォルト構成を設定して初期化します。ログイン構成エンドポイントの取得に使用される正しい組織 URL を設定してください。詳細については、gdcloud CLI のインストールをご覧ください。
• 認証プラグイン gdcloud-k8s-auth-plugin をインストールします。詳細については、gdcloud CLI 認証をご覧ください。

重要: 次の手順は、ルート アカウントではなく、ユーザー アカウントを使用してシステムで実行してください。gdcloud CLI は、ルートモードではブラウザを自動的に開きません。

クラスタにログインする手順は次のとおりです。

1. クラスタの kubeconfig ファイルを保存するパスをエクスポートします。

     export KUBECONFIG=CLUSTER_KUBECONFIG
   

   CLUSTER_KUBECONFIG は、kubeconfig ファイルを保存するディレクトリのパスに置き換えます。

2. gdcloud CLI インスタンスを認証してログインします。認証には次の 2 つの方法があります。

   • 標準ブラウザ ログイン: ブラウザからログインするときにこの認証フローを使用します。

       gdcloud auth login
     

   • セカンダリ デバイスのログイン: メインのデバイスでブラウザを使用できない場合は、この認証フローを使用します。このフローでは、ブラウザ アクセス権のないメインのデバイスでログインを開始し、ブラウザ アクセス権のあるセカンダリ デバイスでログインを続行します。

     ブラウザのないメインのデバイスでログインを開始します。

       gdcloud auth login --no-browser
     

     KUBECONFIG 環境変数は、組織内のすべての API サーバーとクラスタの kubeconfig ファイルで更新されます。KUBECONFIG 変数が設定されていない場合、kubectl CLI は $HOME/.kube/config に保存されているデフォルトの kubeconfig ファイルを使用します。

     kubeconfig ファイルの編集をスキップするには、コマンドに --skip-kubeconfig-update フラグを追加します。次に例を示します。

       gdcloud auth login --no-browser --skip-kubeconfig-update
     

     出力された gdcloud CLI コマンド出力をコピーし、ブラウザ アクセス権のあるマシンで実行します。

3. ウェブページの手順に沿ってログインを完了します。

   ログインが正常に完了すると、ブラウザに「認証に成功しました。このウィンドウを閉じてください。

4. ターミナルの指示に沿って操作します。ログインに成功すると、ターミナルに「You are now logged in」というメッセージが表示されます。

   注: x509: certificate signed by unknown authority エラーが表示された場合、ワークステーションは GDC で使用されている CA 証明書を信頼していません。組織の手順に沿って、ワークステーションの信頼できる証明書ストアを確認します。
   警告: 未確認の証明書で --login-config-cert を使用すると、中間者攻撃を受けやすくなります。不明なソースの CA 証明書を信頼するのではなく、ワークステーションのトラストストアのみを使用するようにしてください。

5. ユーザー ID kubeconfig ファイルを変数としてエクスポートします。

     export KUBECONFIG=/tmp/admin-kubeconfig-with-user-identity.yaml
   

6. ユーザー ID を使用して kubeconfig ファイルを生成します。

     gdcloud clusters get-credentials CLUSTER_NAME --zone ZONE
   

   ZONE は、ゾーン名に置き換えます。

   注: 使用可能なクラスタ名の一覧は、ログイン構成 URL（
   https://GDC_URL/.well-known/login-config?allZones=true）で確認できます。

   kubeconfig ファイルがユーザー ID で生成されます。次の YAML ファイルは、例を示しています。

   apiVersion: v1
   clusters:
   - cluster:
       certificate-authority-data: <REDACTED>
       server: https://10.200.0.32:443
     name: cluster-name
   contexts:
   - context:
       cluster: cluster-name
       user: cluster-name-anthos-default-user
     name: cluster-name-cluster-name-anthos-default-user
   current-context: cluster-name-cluster-name-anthos-default-user
   kind: Config
   preferences: {}
   users:
   - name: cluster-name-anthos-default-user
     user:
       exec:
         apiVersion: client.authentication.k8s.io/v1
         args:
         - --audience=root-admin
         command: gdcloud-k8s-auth-plugin
         env: null
         installHint: Run 'gdcloud components install gdcloud-k8s-auth-plugin' to use plugin
         interactiveMode: Never
         provideClusterInfo: false
   

7. クラスタにアクセスできることを確認するには、生成された kubeconfig ファイルを使用してユーザー ID でログインします。

   kubectl --kubeconfig /tmp/admin-kubeconfig-with-user-identity.yaml version
   

ログアウト

ログアウトを確認する手順は次のとおりです。

コンソール

ウェブ UI からログアウトするには、メニューバーで [ログアウト] をクリックします。

CLI

CLI からログアウトします。

gdcloud auth revoke

kubeconfig ファイルを手動で生成する

KRM API を直接呼び出して kubectl CLI でリソースを管理している場合は、管理するリソースのタイプに応じて、リソースをホストするクラスタの kubeconfig ファイルを生成する必要があります。使用可能なクラスタとサーバーは次のとおりです。

クラスタ	名前
ルート管理クラスタ	root-admin
ルート グローバル API サーバー	global-api
組織管理者クラスタ（v1 組織）	ORG_NAME-admin
システム クラスタ（v1 組織）	ORG_NAME-system
組織インフラストラクチャ クラスタ（v2 組織）	ORG_NAME-infra
Management API サーバー（v2 組織）	ORG_NAME-admin
組織管理者のグローバル API サーバー	global-api
ユーザー クラスタ	CLUSTER_NAME

また、GDC ユニバースの構成を把握して、ゾーンリソースをデプロイするゾーン、またはグローバル リソースのグローバル API サーバーを決定する必要があります。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。

操作するリソースがグローバル リソースかゾーンリソースかを判断します。不明な場合は、リソースの専用ドキュメントをご覧ください。

リソースタイプに基づいて、該当する設定を完了します。

ゾーンリソース

ゾーン クラスタの kubeconfig ファイルを生成するには、次の操作を行います。

1. 利用可能なすべてのゾーンを表示します。

   gdcloud zones list
   

   カスタム リソースをホストするゾーンの名前をメモします。

2. ZONE 環境変数を、ゾーンリソースをホストするゾーンに設定します。

   export ZONE="ZONE"
   

   ZONE は、ゾーン名に置き換えます。

3. CLUSTER 環境変数を設定します。

   export CLUSTER="CLUSTER_NAME"
   

   CLUSTER_NAME は、リソースをホストするクラスタの名前に置き換えます。

4. ターゲット ゾーンのクラスタ kubeconfig ファイルを生成し、認証情報を検証します。

   export KUBECONFIG=${HOME}/${CLUSTER:?}-kubeconfig.yaml
   rm ${KUBECONFIG:?}
   gdcloud clusters get-credentials ${CLUSTER:?} --zone ${ZONE:?}
   [[ $(kubectl config current-context) == *${CLUSTER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure"
   

   コマンド rm ${KUBECONFIG:?} は、ホーム ディレクトリ内の既存の kubeconfig ファイルを削除します。既存の kubeconfig ファイルを明示的に削除しなくても、kubeconfig ファイルは新しく生成された kubeconfig ファイルで上書きされます。既存のファイルを上書きまたは削除したくない場合は、別の安全な場所にバックアップしてください。

グローバル リソース

グローバル API サーバーの kubeconfig ファイルを生成する手順は次のとおりです。

1. GLOBAL_API_SERVER 環境変数を設定します。

   export GLOBAL_API_SERVER="global-api"
   

2. グローバル API サーバーの kubeconfig ファイルを生成し、認証情報を検証します。

   export KUBECONFIG=${HOME}/${GLOBAL_API_SERVER:?}-kubeconfig.yaml
   rm ${KUBECONFIG:?}
   gdcloud clusters get-credentials ${GLOBAL_API_SERVER:?}
   [[ $(kubectl config current-context) == *${GLOBAL_API_SERVER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure"
   

   コマンド rm ${KUBECONFIG:?} は、ホーム ディレクトリ内の既存の kubeconfig ファイルを削除します。既存の kubeconfig ファイルを明示的に削除しなくても、kubeconfig ファイルは新しく生成された kubeconfig ファイルで上書きされます。既存のファイルを上書きまたは削除したくない場合は、別の安全な場所にバックアップしてください。

セッションの非アクティブ ログアウト

セッションで 15 分以上操作がないと、GDC コンソールと gdcloud CLI からログアウトされます。GDC では、セッションの非アクティブ状態とは、開いているセッション中にカーソルやキーボードの操作など、ユーザーによるアクティブな操作がない期間を指します。アクティブ セッションは、ユーザー アクティビティがある場合、最大 12 時間継続します。

コンソール

セッションが非アクティブになると、GDC コンソールからログアウトされます。GDC コンソールが非アクティブ状態のためにログアウトする 2 分前に、ログアウトを警告するダイアログが表示されます。

操作がないためログアウトすると、次の画面が表示されます。

GDC コンソールに再度ログインするには、ID プロバイダを選択してログイン認証情報を追加します。モニタリング ダッシュボードなどのサービスを使用しているときに、GDC コンソールが非アクティブ状態のためにログアウトした場合は、再度ログインしてアクセスしてください。

CLI

セッションが非アクティブになると、gdcloud CLI からログアウトします。gdcloud CLI からログアウトした後、コマンドを実行しようとすると、承認エラーが発生します。

Error: error when creating kube client: unable to create k8sclient: Unauthorized

gdcloud CLI に再度ログインするには、ログインの CLI の手順に沿って操作します。

注: gdcloud init や gdcloud config など、API リクエストを行わないコマンドはアクティビティにカウントされません。これらのコマンドを使用すると、gdcloud CLI はログアウトします。

kubectl

gdcloud CLI は、セッションが非アクティブになると kubeconfig ファイルを期限切れにします。非アクティブ状態の後に kubectl コマンドを実行しようとすると、認証エラーが発生します。

error: You must be logged in to the server (Unauthorized)

再度ログインして kubeconfig ファイルを使用するには、ログインの CLI 手順に沿って操作します。セッションがタイムアウトするたびに、kubeconfig ファイルを再生成する必要があります。