Google Distributed Cloud（GDC）エアギャップには、ユーザーが設定された最大保持ポリシー GDCHRestrictAttributeRange を超えないように制限する制約があります。この制約は、Anthos Config Management の Policy Controller によって、組織管理クラスタのバケット カスタム リソース（CR）に適用されます。つまり、デフォルトでは、システム サービス アカウント、システム ユーザー、system:masters グループ内のユーザーのみがファイナライザーを削除できます。概要の手順では、バケット CR の保持ポリシーの上限を引き上げる方法について説明します。
前提条件
- ツール: kubectl CLI
- 必要なアクセス権: クラスタの KUBECONFIG ファイルを生成する
- 必要なアクセス権: クラスタでロール
Policy Adminを取得する
クラスタの KUBECONFIG ファイルを生成する
Kubectl コマンドが機能するには、有効な KUBECONFIG ファイルが必要です。このプロセスでは、ルート管理者、組織管理者、組織システム、ユーザー クラスタの KUBECONFIG ファイルを生成する手順を説明します。
前提条件
続行する前に、次の点をご確認ください。
gdcloudがインストールされている。kubectlCLI がインストールされている。ワークステーションにインストールされた認証局（CA）署名付き証明書。
組織名。
（GDC）ルート URL。OC IT 管理者からルート URL を提供してもらう必要があります。
必要な環境変数を設定する
このセクションの手順に沿って、org-admin、system、または任意のユーザー クラスタの KUBECONFIG ファイルを生成します。
次のコマンドを実行して、現在のターミナルで後で使用する環境変数
ORGを定義します。ORGは組織名です。export ORG=次のコマンドを実行して、現在のターミナルで後で使用する環境変数
CONSOLE_URLを定義します。export CONSOLE_URL=https://console.${ORG:?}.$GDC_URL/ gdcloud config set core/organization_console_url ${CONSOLE_URL:?}GDC_URLは、GDC プロジェクトのベース URL に置き換えます。
クラスタへのログイン
次のコマンドを実行してログインします。
gdcloud auth login --no-browser出力された gdcloud コマンドをコピーして、ブラウザにアクセスできるマシンで実行します。
印刷された URL をコピーして、ウェブブラウザのアドレスバーに貼り付けます。
ウェブページの手順に沿ってログインを完了します。
ログインが正常に完了すると、ブラウザに「Authentication successful. このウィンドウを閉じてください。
ターミナルの指示に沿って操作します。ログインに成功すると、ターミナルに「You are now logged in」というメッセージが表示されます。
KUBECONFIG ファイルを生成する
次のコマンドを実行して、現在のターミナルで後で使用する環境変数
CLUSTERを定義します。CLUSTERは、クラスタの任意の名前です。export CLUSTER=次の表を参照して、ORGANIZATION-NAME と CLUSTER-NAME を適切な値に置き換えてクラスタの名前を取得します。
クラスタ クラスタ名 ルート管理者 root-admin 組織管理者 ORGANIZATION-NAME-admin 組織システム ORGANIZATION-NAME-system ユーザー CLUSTER-NAME 各名前は次のものを表しています。
- ルート管理クラスタ名は
root-adminです。 amiraという名前の組織の組織管理者と組織システム クラスタ名は、それぞれamira-adminとamira-systemです。- ユーザー クラスタのクラスタ名は、クラスタ名です。
- ルート管理クラスタ名は
次のコマンドを実行して、KUBECONFIG ファイルを生成し、認証情報を検証します。
sh export KUBECONFIG=${HOME}/${CLUSTER:?}-kubeconfig.yaml rm ${KUBECONFIG:?} gdcloud clusters get-credentials ${CLUSTER:?} [[ $(kubectl config current-context) == *${CLUSTER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure"コマンドは次の出力を返します。Success. Your kubeconfig is at /usr/local/google/home/iris/kubeconfig-amira-admin.yaml
クラスタでポリシー管理者ロールを取得する
このプロセスでは、クラスタへの一時的な昇格アクセスを取得できます。
前提条件
続行する前に、次の点をご確認ください。
- GitLab リクエスト承認者として機能する別の IO。IO には、GitLab リクエストを承認する権限が必要です。
- アクセスする必要があるクラスタ名。例:
root-admin、org-1-admin。 - 引き受けるロールのタイプ。例:
RoleClusterRole、ProjectRole、OrganizationRole。 - 引き受けるロール。
- 必要なアクセスの名前空間。
ClusterRoleとOrganizationRoleでは不要です。 - OC IT ワークステーションへのアクセス権。
- GitLab の認証情報。
elevated-access-script を実行する
ワークステーションの
private-cloud/operations/tools/ディレクトリからelevated-access-script.shスクリプトを実行します。「Please enter the GDCH_URL of the cluster...」という質問に
$GDCH_URLで答えます。「Enter Gitlab username:」という質問に、Gitlab へのログインに使用するユーザー名で答えます。
「Enter Gitlab personal access token:」という質問に対して、アカウントの個人アクセス トークンを入力します。個人用アクセス トークンを作成する手順は次のとおりです。
https://gitlab.$GDCH_URL/gdch/iacに移動します。IO Gitlab アカウントにログインします。アバターを選択します。
[プロフィールを編集] を選択します。
ナビゲーション メニューで [アクセス トークン] を選択します。
トークンの名前と有効期限を入力します。
目的のスコープを選択します。
[個人用アクセス トークンを作成] を選択します。
スクリプトは、リポジトリ
iacをローカル ディレクトリにクローンします。「Enter your IdP prefix」という質問に回答します。
IdP Prefixは、GDC クラスタ内のすべてのユーザー名の前に付加される、各 ID プロバイダに固有の接頭辞です。この接頭辞は、次のいずれかの方法で確認できます。- Watch Commander に相談する
- GDC Setup からの手順の取得（具体的には、オペレーター ユーザーガイドの「Identity and Access Management」セクション）。
この接頭辞の一般的な形式は、一連の単語の後に区切り文字（
gdch-infra-operator-）が続くものです。[Enter your username]（ユーザー名を入力）という質問に、ID プロバイダへのログインに使用するユーザー名で答えます。
「Enter the cluster you need the role for」という質問に、ロールが必要なクラスタの名前で答えます。
スクリプトを実行すると、Kubernetes ロールタイプを選択するよう求められます。リクエストするロールの種類を入力します。
「引き受ける必要のあるロールを入力してください」という質問に、ロールの名前で答えます。
ロールのアクセス期間を入力します。推奨されるアクセス期間は 3 時間です。
このスクリプトは 3 つの YAML ファイルを生成します。
./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/kustomization.yaml./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/kustomization.yaml./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/${ROLE}-binding.yaml
Yを押して各ファイルが正しいことを確認するか、Nを押してvimでファイルを編集します。すべてのファイルを確認すると、スクリプトはこれらのファイルを GitLab の
elevated_accessブランチに push し、merge リクエストを作成します。
昇格したアクセス リクエストを確認して承認する
以下に、昇格されたアクセス権のリクエストの確認と承認に対して行われるアクションを示します。
- 別の IO が、ポリシー構成ファイルを含む GitLab リクエストを確認し、リクエストを適切に承認します。
- IO がリクエストを承認すると、システムはリクエストされた期間のアクセス権を付与します。
- システムは、設定された有効期限が切れるとアクセス権を取り消します。
パッチ制約
必要なアクセス権を取得したら、次のコマンドを実行して、新しいバケット保持ポリシーの最大値を設定します。この例では、新しい最大値は 120 日ですが、コマンドをプラットフォーム管理者（PA）が要求する値に更新してください。
kubectl patch GDCHRestrictAttributeRange restrict-bucket-retention-policy -p '{"spec":{"parameters":{"attributeMaxValue":120}}}' --type=merge
出力は次のようになります。
gdchrestrictattributerange.constraints.gatekeeper.sh/restrict-bucket-retention-policy patched