このページは Cloud Translation API によって翻訳されました。

23. Infrastructure as Code の設定

推定所要時間: 60 分

操作可能なコンポーネントのオーナー: IAC

スキルプロファイル: デプロイエンジニア

Google Distributed Cloud（GDC）エアギャップの Infrastructure as Code（IaC）は、次の 2 つのシステムで構成されています。

Config Sync は、クラスタレベルのリソースと共有サービスの管理に Distributed Cloud Infrastructure as Code（IaC）で使用されるコンポーネントです。
GitLab は、Config Sync の信頼できる情報源（SoT）として機能する Git リポジトリをホストします。ターゲットクラスタは、リポジトリの SoT から Config Sync が管理するクラスタです。
- GitLab には、ポリシーと構成の変更に多者間承認（MPA）を実装するためのコードレビューシステムが含まれています。

デプロイには次の 2 つのゾーンタイプが関与します。

アンカーゾーン: グローバルコントロールプレーンにすでに含まれているゾーン。最初のゾーンは、デプロイのアンカーゾーンです。
参加ゾーン: グローバルコントロールプレーンに参加するゾーン。

Config Sync は、root-admin クラスタと organization-admin クラスタの Kubernetes オブジェクトを管理します。プライマリ root-admin クラスタの GitLab によって提供される Distributed Cloud IaC リポジトリから読み取るように構成されています。

Distributed Cloud は、ブートストラップ中に IaC をインストールします。次の手動の手順を実行して、IaC の設定を完了します。

23.1. 最初のゾーンの IaC を設定する

このセクションでは、最初のデプロイゾーンで IaC を設定する手順について説明します。

23.2. 前提条件

ルート管理クラスタをブートストラップしました。
OC IT の Active Directory フェデレーションサービス（ADFS）インスタンスに SAML クライアントを作成し、GitLab で ID 連携クライアントとして使用します。

23.3. GitLab への Day 0 アクセス

https://iac.GDC_URL で GitLab ウェブコンソールを開きます。GDC_URL は、CIQ で指定されたドメインです。

# Use the root kubeconfig of the root admin cluster.
export ANCHOR_KUBECONFIG=ANCHOR_ZONE_KUBECONFIG
echo https://$(kubectl --kubeconfig $ANCHOR_KUBECONFIG get dnsregistrations \
     -n gitlab-system iac -o jsonpath='{.status.fqdn}')

day 0 のユーザー名 ioadmin を使用します。

次のコマンドを実行して、パスワードを取得します。

export IO_ADMIN_PWD=$(kubectl --kubeconfig $ANCHOR_KUBECONFIG \
  get secret gitlab-basic-users -n gitlab-system  \
  -o jsonpath='{.data.admin}' | base64 -d)

ログインして [メニュー] > [プロジェクト] > [プロジェクト gdch / iac を探索] に移動し、iac Git リポジトリが作成されていることを確認します。

23.4. 管理者ユーザーを作成する

ADFS で専用の管理者ユーザーを作成します。管理以外の目的で使用することはできません。また、拡張子は「-ga」にする必要があります。初期管理者ユーザーは、Active Directory フェデレーションサービス（ADFS）で使用しているのと同じ email をここで使用する必要があります。

次のコマンドを実行して、新しいユーザーを作成します。

export NEW_USER_NAME=NEW_USER_NAME
export NEW_USER_USERNAME=NEW_USERNAME
export NEW_USER_PWD=NEW_USER_PWD
export NEW_USER_EMAIL=NEW_USER_EMAIL
export GDC_URL=GDC_URL
export TOKEN=$(curl -X POST https://iac.$GDC_URL/oauth/token \
    -d "grant_type=password&username=ioadmin&password=${IO_ADMIN_PWD}" \
    | jq -r '.access_token')
USERID=$(curl -X GET https://iac.$GDC_URL/api/v4/users \
    -d access_token=${TOKEN} -d username=ioadmin |\
    sed -E 's/.*"id":"?([^,"]*)"?.*/\1/')
curl -X POST https://iac.$GDC_URL/api/v4/users \
    -d username=${NEW_USER_USERNAME} -d password=${NEW_USER_PWD} -d name=${NEW_USER_NAME} \
    -d email=${NEW_USER_EMAIL} -d admin=true -d access_token=${TOKEN} 
curl -X POST https://iac.$GDC_URL/oauth/revoke \
    -d client_id=${USERID} -d "token=${TOKEN}"

23.5. GitLab ライセンスを更新する

GitLab の多くの機能は、「Ultimate」ライセンスがないと機能しません。この手順では、GDC に付属している一時ライセンスをサイト独自のライセンスに置き換えます。詳細については、ライセンスファイルまたはキーを使用して GitLab EE を有効にするをご覧ください。

受け取ったサイトのライセンスキーは、.gitlab-license 拡張子の付いた base64 エンコードの ASCII テキストファイルです。このキーを使用して GitLab を有効にします。

ioadmin として GitLab ウェブコンソールにログインします。
ナビゲーションバーで、[メニュー]、[管理者] の順に選択します。
ナビゲーションメニューで、[設定]、[全般] の順に選択します。
[ライセンスを追加] 領域で、ファイルをアップロードするかキーを入力してライセンスを追加します。
[利用規約] チェックボックスをオンにします。
[ライセンスを追加] を選択します。

23.6. GitLab リポジトリを設定する

ConfigSync は、root-admin クラスタと org-admin クラスタの Kubernetes オブジェクトを管理し、root-admin クラスタの GitLab によって提供される Distributed Cloud IaC リポジトリから読み取るように構成されています。

Configsync が構成を使用し、必要な Kubernetes クラスタに適用できるように、初期 GitLab フォルダを設定する必要があります。

infrastructure
│   └── zonal
│     └── zones
│         ├── ${anchor_zone_name}
│           ├── root-admin
│             ├── kustomization.yaml
│   └── global
│     └── orgs
│         ├── root
│           ├── kustomization.yaml

次の手順に沿って、初期ファイル構造を作成します。

[Menu -> Explore Projects] から iac リポジトリを開きます。
[Web IDE] を開きます。
/infrastructure/zonal/zones/${anchor_zone_name}/root-admin/kustomization.yaml に次の内容のファイルを作成します。
```
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: root-admin-kustomization
```
[コミット] ボタンをクリックします。
[Commit to the main branch] を選択して確定します。

23.7. 複数の関係者による承認（MPA）を設定する

このセクションでは、iac リポジトリへのすべてのマージリクエストで承認を必須とし、main ブランチへの直接コミット（マージリクエストの作成なし）を禁止して、複数の関係者による承認（MPA）を適用するようにシステムを構成します。

23.7.1. GitLab でマージリクエストの承認を有効にする

iac リポジトリに移動します。
ウェブ IDE を使用して、ルートフォルダに CODEOWNERS という名前のファイルを作成し、最初の手順として Distributed Cloud グループをリポジトリオーナーとして追加します。
```
[Repository Owners]
* @gdch
```
CODEOWNERS ファイルに追加されたユーザーのみが、iac リポジトリでマージリクエストを承認できます。この汎用ファイルはセットアップのみを目的としています。きめ細かい承認権限の詳細な手順については、IAC-R0007 をご覧ください。
[Commit] ボタンをクリックします。
[Commit to the main branch] を選択して確定します。
CODEOWNERS ファイルにユーザーを追加するには、CODEOWNERS の既存のユーザーが承認するマージリクエストを作成します。

23.8. Active Directory フェデレーションサービス（ADFS）を GitLab に接続する

GitLab の Auth フレームワークを使用して、SAML クライアントで ADFS を GitLab に接続できます。

ID プロバイダにプライベート認証局を使用している場合は、GitLab インスタンスに追加する必要があります。ADFS CA 証明書の base64 バージョンを取得し、Secret に格納します。

cat <<EOF > adfs-ca-cert-secret.yaml
apiVersion: v1
data:
  tls.crt: ADFS_CA_CERTIFICATE_BASE64
kind: Secret
metadata:
  name: adfs-ca-cert-secret
  namespace: gitlab-system
type: Opaque
EOF

kubectl apply -f adfs-ca-cert-secret.yaml

23.8.1. SAML 認証用に ADFS を構成する

Helm 構成を使用して GitLab を ADFS に接続する前に、ADFS で SAML クライアントを作成する必要があります。Windows インスタンスで、次の操作を行います。

AD FS 管理アプリを管理者として実行します。
[AD FS] ディレクトリで、[証明書利用者信頼] フォルダをクリックします。[アクション] パネルで、[証明書利用者信頼の追加] をクリックします。
[証明書利用者信頼の追加ウィザード] が開きます。最初の手順で、[要求に対応する] を選択し、[開始] をクリックします。
[証明書利用者についてのデータを手動で入力する] を選択して、[次へ] をクリックします。
[表示名] フィールドと [メモ] フィールドに、ADFS インスタンスに関するわかりやすい情報を入力します。[Next] をクリックします。
[次へ] をクリックして、[証明書の構成] ステップをスキップします。
[SAML 2.0 WebSSO プロトコルのサポートを有効にする] チェックボックスをオンにします。[証明書利用者 SAML 2.0 SSO サービスの URL] に次の値を入力します。 https://iac.GDC_URL/users/auth/saml/callback。

GDC_URL は、GDC の組織の URL に置き換えます。

IaC の名前を指定し、以下を追加します。

https://iac.GDC_URL.sesame.street https://iac.GDC_URL.sesame.street/users/auth/saml/callback

[識別子の構成]、[アクセス制御ポリシーの選択]、[信頼を追加する準備] の各ステップで [次へ] をクリックして、ウィザードを終了します。

注: [識別子の構成] ページの手順をスキップするには、次の証明書利用者 ID を追加します。
```
  # Replace GDC_URL with the cells URL, for example, bert.sesame.street
  https://iac.GDC_URL
  https://iac.GDC_URL/users/auth/saml/callback
```
新しく作成した証明書利用者信頼で表示が更新されます。アイテムを右クリックし、[要求発行ポリシーの編集] を選択します。
[ルールを追加] ボタンをクリックし、[規則の種類の選択] ステップで、[要求規則テンプレート] の [LDAP 属性を要求として送信] を選択します。[次へ] をクリックします。
[要求規則の構成] ステップで、次のパラメータを入力します。
1. [Claim rule name] フィールドに「Email」と入力します。
2. [属性ストア] リストで、[Active Directory] を選択します。
3. [LDAP 属性と送信クレームタイプのマッピング] テーブルの [LDAP 属性] 列で、E-Mail-Addresses を選択または入力します。
4. テーブルの [Outgoing claim type] 列で、E-Mail Address を選択または入力します。
5. ウィザードを終了します。
[ルールを追加] ボタンをクリックします。
項目を右クリックし、もう一度 [Edit Claim Issurance Policy] をクリックします。
[規則の種類の選択] ステップで、[入力方向の要求を変換] の [要求規則テンプレート] を選択します。[次へ] をクリックします。
[要求規則の構成] ステップで、次のパラメータを入力します。
1. [Claim rule name] フィールドに「Transform email to nameid」と入力します。
2. [Incoming claim type] フィールドで、E-Mail Address を選択または入力します。
3. [Outgoing claim type] フィールドで、Name ID を選択または入力します。
4. [Outgoing name ID format] フィールドで、Persistent Identifier を選択または入力します。
5. [すべての要求値をパススルーする] オプションを選択します。
6. ウィザードを終了します。

23.8.2. GitLab に SAML 構成を追加する

このセクションでは、GitLab に SAML 構成を追加する手順について説明します。

23.8.2.1. ID プロバイダに GitLab を登録する

ADFS で SAML クライアント構成を開きます。GitLab では、IdP との統合に次の値が必要です。

assertion_customer_service_url - ユーザーの認証後、IdP はこの URL にリダイレクトします。https://iac.GDC_URL/users/auth/saml/callback に設定します。

GDC_URL は、GDC の組織の URL に置き換えます。
idp_cert_fingerprint - GitLab はこのフィンガープリントを使用して、受信した SAML メッセージの証明書を検証します。ADFS で idp_cert_fingerprint を見つける手順は次のとおりです。
1. アプリ AD FS Management を管理者として実行します。
2. ディレクトリツリーの [AD FS] > [サービス] > [証明書] で、[証明書] フォルダをクリックします。[トークン署名] セクションに証明書が表示されます。その証明書を右クリックし、[証明書の表示] を選択します。
3. [証明書] ウィンドウで、[Details] タブに移動します。Thumbprint という項目が表示されるまで、リストをスクロールします。項目をクリックして、コンソールに表示された内容をコピーします。
idp_sso_target_url - GitLab は、SAML で認証を行うときにこのエンドポイントをターゲットにします。ADFS で idp_sso_target_url を見つける手順は次のとおりです。
1. AD FS 管理アプリを管理者として実行します。
2. ディレクトリツリーの [AD FS] > [サービス] で [エンドポイント] フォルダをクリックします。
  
  エンドポイント。
3. 中央の画面で、タイプが [SAML 2.0/WS-Federation] の行を探します。ターゲットエンドポイントは ADFS URL とターゲットエンドポイントです。たとえば、インスタンスのドメイン名が https://ocit.gdch.test/ で、ターゲットエンドポイントが /adfs/ls の場合、idp_sso_target_url は https://ocit.gdch.test/adfs/ls になります。

issuer - GitLab が自身を識別するために使用する URL。https://iac.GDC_URL を使用します。

上記の IdP の値を準備し、custom_saml.yaml というカスタム構成に書き込みます。この YAML ファイルを編集して、SAML クライアントに必要な構成を取得します。

cat <<EOF > custom_saml.yaml
name: saml
label: "ADFS SAML" # This is the label the login button will use.
args:
  assertion_consumer_service_url: "https://iac.GDC_URL/users/auth/saml/callback"
  idp_cert_fingerprint: "ADFS_IDP_CERT_FINGERPRINT"
  idp_sso_target_url: "ADFS_IDP_SSO_TARGET_URL"
  issuer: "https://iac.GDC_URL"

  # These parameters are necessary for ADFS to connect to GitLab. Do not change unless you are sure of what you're doing.
  name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
  attribute_statements: { email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'] }
EOF

準備ができたら、構成を custom-gitlab-saml-provider という Secret として適用します。

cat <<EOF > custom-gitlab-saml-provider.yaml
apiVersion: v1
data:
  provider: |
  $(cat custom_saml.yaml | base64 -w 0)
kind: Secret
metadata:
  name: custom-gitlab-saml-provider
  namespace: gitlab-system
  annotations:
    "helm.sh/hook": post-install,post-upgrade
    "helm.sh/hook-weight": "-5"
EOF
kubectl apply -f custom-gitlab-saml-provider.yaml

このシークレットは、subcomponentoverride.yaml の作成時に使用できます。変数について詳しくは、GitLab のドキュメントをご覧ください。

cat <<EOF > subcomponentoverride.yaml
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: iac-gitlab
  namespace: root
spec:
  subComponentRef: "iac-gitlab"
  backend:
    operableParameters:
      omniauth:
        enabled: true
        providers:
        - secret: custom-gitlab-saml-provider
      certificates:
        customCAs:
        - secret: adfs-ca-cert-secret
        - configMap: trust-store-root-ext
EOF
kubectl apply -f subcomponentoverride.yaml

これにより、サブコンポーネントのオーバーライドが作成されます。構成が作成されたことを確認するには、次のコマンドを実行します。 sh kubectl get subcomponentoverride -n root

出力は次のようになります。

NAME            AGE
iac-gitlab   1s

23.8.2.2. 最初にログインした SAML ユーザーを初期化する

SAML を有効にすると、ローカルログインは削除されます。ローカルログインを再度有効にして ioadmin にアクセスするには、緊急アクセス手順を行う必要があります。

管理者ユーザーの作成で作成された最初の初期化済み管理者は、管理者として追加の変更なしで機能します。プロジェクトにアクセスできないようにする必要があります。Distributed Cloud プロジェクトにユーザーを追加するには、ADFS から新しいユーザーをオンボーディングするをご覧ください。

23.8.3. ADFS 接続を確認する

GitLab webservice Pod のステータスを確認します。

kubectl --kubeconfig $KUBECONFIG get pod -l app=webservice,release=gitlab -n gitlab-system

名前	準備完了	ステータス	年齢
gitlab-webservice-default-5d99b4d7c7-9fmln	2/2	実行中	4 分 6 秒
gitlab-webservice-default-5d99b4d7c7-w99p4	2/2	実行中	96s
gitlab-webservice-default-7884d4c8b9-qjhtv	2/2	終了中	18 時間前

https://iac.GDC_URL に移動し、この画面が表示されることを確認します。この画面には、SSO ログインに使用する [ADFS SAML] ボタンが表示され、直接ログイン用のユーザー名とパスワードのフィールドは表示されません。
[ADFS SAML] をクリックします。ADFS へのログインを求められることを確認します。
ADFS にログインしたら、GitLab にログインして、アプリケーションを操作できることを確認します。

23.9. Day 0 管理者アカウントをロックする

SAML を有効にした後、ウェブインターフェースのパスワード認証を無効にしてから、API アクセスが維持されるため、ioadmin のパスワードをリセットします。

次のスクリプトを実行します。

  export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
  export PWD=$(kubectl get secret gitlab-basic-users -n gitlab-system -o yaml \
      | grep admin | head -n1 | awk '{print $2}' | xargs echo | base64 -d)
  export TOKEN=$(curl -X POST https://iac.GDC_URL/oauth/token \
      -d "grant_type=password&username=ioadmin&password=${PWD}" \
      | jq -r '.access_token')
  curl -X PUT  https://iac.GDC_URL/api/v4/application/settings \
      -d access_token=${TOKEN} \
      -d password_authentication_enabled_for_web=false
  NEWPASS=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
  USERID=$(curl -X GET https://iac.GDC_URL/api/v4/users \
      -d access_token=${TOKEN} -d username=ioadmin |\
      jq -r '.[] | .id')
  curl -X PUT  https://iac.GDC_URL/api/v4/users/${USERID} \
      -d access_token=${TOKEN} -d username=ioadmin \
      -d "password=${NEWPASS}" \
      -d user_id=${USERID}
  curl -X POST https://iac.GDC_URL/oauth/revoke \
      -d client_id=${USERID} -d "token=${TOKEN}"

新しいパスワードをシークレット gitlab-basic-users に保存します。

  kubectl patch secret gitlab-basic-users -n gitlab-system --type=json -p'[{"op": "replace", "path": "/data/admin", "value": '"$(echo $NEWPASS | base64 -w0)"'}]'

OI ADFS のアカウントを使用してログインします。

23.10. 参加ゾーンの IaC を設定する

このセクションでは、デプロイの結合ゾーンで IaC を設定する手順について説明します。

23.11. 前提条件

参加ゾーンを設定する前に、ルート管理クラスタをブートストラップする必要があります。

23.12. configsync 認証情報を構成する

Config Sync の認証情報を構成する手順は次のとおりです。

アンカーゾーンのルート管理クラスタに接続します。

Config Sync の認証情報を取得します。

kubectl --kubeconfig $ANCHOR_KUBECONFIG get secret -n config-management-system iac-creds-replica -o json |\
    jq 'del(.metadata.creationTimestamp, .metadata.resourceVersion, .metadata.uid)' > iac-creds-replica.json

iac-creds-replica.json ファイルをコピーします。
参加するゾーンのルート管理クラスタに接続します。
iac-creds-replica.json ファイルを貼り付けます。

Config Sync 認証情報をルート管理クラスタに適用します。

# Use the root kubeconfig of the root admin cluster.
export JOINING_KUBECONFIG=JOINING_ZONE_KUBECONFIG
kubectl --kubeconfig $JOINING_KUBECONFIG apply -f iac-creds-replica.json

Config Sync の認証情報が構成されていることを確認します。

kubectl --kubeconfig $JOINING_KUBECONFIG get secret -n config-management-system \
    iac-creds-replica -o yaml

23.13. Config Sync の信頼できる情報源を構成する

Config Sync の信頼できる情報源を構成する手順は次のとおりです。

アンカーゾーンのルート管理クラスタに接続します。

GitLab の FQDN を取得します。

export primaryDnsFQDN=$(kubectl --kubeconfig $ANCHOR_KUBECONFIG get DNSRegistration \
    -n gitlab-system iac -o jsonpath='{.status.fqdn}')

参加するゾーンのルート管理クラスタに接続します。

IaC SubcomponentOverride ファイルを作成します。

echo "apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
    name: iac
    namespace: root
spec:
    subComponentRef: "iac-configsync"
    backend:
        operableParameters:
            primaryDnsFQDN: ${primaryDnsFQDN}" > iac-subcomponentoverride.yaml

Config Sync ターゲットを構成します。

kubectl --kubeconfig $JOINING_KUBECONFIG apply -f iac-subcomponentoverride.yaml

Config Sync Git リポジトリが構成されていることを確認します。

kubectl --kubeconfig $JOINING_KUBECONFIG get RootSync -n config-management-system \
    root-sync -o jsonpath='{.spec.git.repo}'

アンカーゾーンと結合ゾーンの両方で、Config Sync にエラーがないことを確認します。
```
kubectl --kubeconfig $JOINING_KUBECONFIG get RootSync \
    -n config-management-system root-sync \
    -o jsonpath='{.status.source.errors[0].errorMessage}'
```
1. root-sync にエラー KNV2004 が含まれている場合、アンカーゾーンまたは結合ゾーンで使用されるディレクトリパスが iac リポジトリに存在しません。次のコマンドを実行して、必要なディレクトリを見つけます。
```
kubectl --kubeconfig $JOINING_KUBECONFIG get RootSync \
    -n config-management-system root-sync
    -o jsonpath='{.spec.git.dir}'
```
2. 前のコマンドで出力されたパスを iac リポジトリに作成し、汎用の kustomization.yaml ファイルを追加します。次に、main ブランチにマージします。
3. 元の get RootSync コマンドを再実行して、Config Sync にエラーがないことを確認します。