Argo CD に関する考慮事項

このトピックでは、EKS Capability for Argo CD を使用する際の重要な考慮事項を示します。具体的には、計画、アクセス許可、認証、マルチクラスターデプロイパターンなどです。

計画

Argo CD をデプロイする前に、以下の点を考慮してください。

リポジトリ戦略: アプリケーションマニフェストの保存場所を決定します (CodeCommit、GitHub、GitLab、Bitbucket)。異なる環境ごとにリポジトリ構造と分岐戦略を計画します。

RBAC 戦略: どのチームやユーザーが管理者、編集者、またはビューワーのアクセス権を持つべきかを計画します。これらを AWS アイデンティティセンターグループまたは Argo CD ロールにマッピングします。

マルチクラスターアーキテクチャ: 単一の Argo CD インスタンスから複数のクラスターを管理するかどうかを決定します。Argo CD に専用の管理クラスターを使用することを検討してください。

Application の編成: Application と ApplicationSet をどのように構造化するかを計画します。Project を使用してチームや環境ごとに Application を編成することを検討してください。

同期ポリシー: アプリケーションを自動的に同期するか、手動で承認するかを決定します。開発環境では自動同期が一般的ですが、本番稼働環境では手動で同期します。

アクセス許可

IAM 機能ロール、信頼ポリシー、セキュリティベストプラクティスの詳細については、「Amazon EKS 機能 IAM ロール」および「EKS 機能のセキュリティに関する考慮事項」を参照してください。

IAM 機能ロールの概要

Argo CD 機能リソースを作成するときに、IAM 機能ロールを指定できます。ACK とは異なり、Argo CD は主に Kubernetes リソースを管理し、AWS リソースを直接には管理しません。一方、次の場合には IAM 機能ロールが必要です。

CodeCommit 統合

CodeCommit リポジトリを使用している場合は、読み取りアクセス許可を付与したポリシーをアタッチします。

{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "codecommit:GitPull"
      ],
      "Resource": "*"
    }
  ]
}

"Resource": "arn:aws:codecommit:us-west-2:111122223333:my-app-repo"

Secrets Manager の統合

Secrets Manager にリポジトリ認証情報を保存する場合は、読み取りアクセスのマネージドポリシーをアタッチします。

arn:aws:iam::aws:policy/AWSSecretsManagerClientReadOnlyAccess

このポリシーには、secretsmanager:GetSecretValue、secretsmanager:DescribeSecret、および KMS 復号アクセス許可という必要なアクセス許可が含まれています。

基本セットアップ

基本的な Argo CD 機能にパブリック Git リポジトリがある場合、信頼ポリシー以外に追加の IAM ポリシーは必要ありません。

認証

AWS アイデンティティセンターの統合

Argo CD マネージド機能を AWS アイデンティティセンター (以前の AWS SSO) と直接統合すると、認証に既存の ID プロバイダーを使用できます。

AWS アイデンティティセンター統合を設定した場合:

アイデンティティセンターアクセス許可セットでアクセスをシンプルにする

AWS アイデンティティセンターでは、Argo CD を使用する際に以下の 2 種類の認証パスを利用できます。

Argo CD API 認証: アイデンティティセンターにより、Argo CD UI と API から SSO 認証を行うことができます。これを設定するには、Argo CD 機能の RBAC ロールマッピングを使用します。

EKS クラスターアクセス: Argo CD 機能は、お客様提供の IAM ロールを使用して、アクセスエントリを基に EKS クラスターで認証します。こうしたアクセスエントリは、アクセス許可を追加または削除するように手動で設定できます。

アイデンティティセンターアクセス許可セットを使用すると、単一の ID で Argo CD クラスターと EKS クラスターの両方にアクセスできるため、ID 管理がシンプルになります。Argo CD アクセス用とクラスターアクセス用の認証情報を別々に維持するのではなく、両方のシステムで 1 つの ID だけを管理すればよいので、オーバーヘッドが軽減されます。

RBAC ロールマッピング

Argo CD には、AWS アイデンティティセンターのユーザーとグループにマッピングできるロールが組み込まれています。

ADMIN: すべてのアプリケーションと設定にフルアクセスできます。アプリケーションの作成、デプロイ、更新、削除が可能です。Argo CD の設定を管理できます。

EDITOR: アプリケーションを作成および変更できます。Argo CD の設定を変更したり、アプリケーションを削除したりすることはできません。

VIEWER: アプリケーションに読み取り専用でアクセスできます。アプリケーションのステータスおよび履歴を表示できます。変更を加えることはできません。

マルチクラスターデプロイ

Argo CD マネージド機能は、マルチクラスターデプロイをサポートしているため、単一の Argo CD インスタンスから開発、ステージング、本番稼働のクラスター全体にわたってアプリケーションを管理できます。

マルチクラスターの仕組み

Argo CD に追加でクラスターを登録する場合:

マルチクラスターの前提条件

追加でクラスターを登録する前に:

クラスターを登録する

Kubernetes シークレットを使用して argocd 名前空間にクラスターを登録します。

ターゲットクラスター ARN を取得します。region-code はターゲットクラスターがある AWS リージョンに置き換え、my-cluster はターゲットクラスターの名前に置き換えます。

aws eks describe-cluster \
  --region region-code \
  --name target-cluster \
  --query 'cluster.arn' \
  --output text

クラスター ARN を使用して、クラスターシークレットを作成します。

apiVersion: v1
kind: Secret
metadata:
  name: target-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
type: Opaque
stringData:
  name: target-cluster
  server: arn:aws:eks:us-west-2:111122223333:cluster/target-cluster
  project: default

シークレットを適用します。

kubectl apply -f cluster-secret.yaml

ターゲットクラスターでアクセスエントリを設定する

アプリケーションのデプロイに必要なアクセス許可を Argo CD 機能ロールに付与するには、ターゲットクラスターでアクセスエントリを設定する必要があります。region-code はターゲットクラスターがある AWS リージョンに置き換え、target-cluster はターゲットクラスターの名前に置き換え、ARN は Argo CD 機能ロール ARN に置き換えます。

aws eks create-access-entry \
  --region region-code \
  --cluster-name target-cluster \
  --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole \
  --type STANDARD \
  --kubernetes-groups system:masters

プライベートクラスターアクセス

Argo CD マネージド機能では、VPC ピアリングや特殊なネットワーク設定を施すことなく、完全にプライベートな EKS クラスターにデプロイできます。AWS が Argo CD 機能とプライベートリモートクラスターとの接続を自動的に管理します。リポジトリのアクセスコントロールと Argo CD RBAC ポリシーが正しく設定されていることを確認します。

クロスアカウントデプロイ

クロスアカウントデプロイの場合は、ソースアカウントの Argo CD IAM 機能ロールをターゲットクラスターの EKS アクセスエントリに追加します。

追加で IAM ロールを作成したり、信頼ポリシーを設定したりする必要はありません。EKS アクセスエントリがクロスアカウントアクセスを処理します。

ベストプラクティス

宣言型ソースを信頼できるソースとして使用する: すべてのアプリケーションマニフェストを宣言型ソース (Git リポジトリ、Helm レジストリ、または OCI イメージ) に保存して、バージョン管理、監査証跡、およびコラボレーションを有効にできます。

適切な RBAC を実装する: AWS アイデンティティセンター統合を使用すると、Argo CD でアプリケーションにアクセスして管理できるユーザーを制御できます。Argo CD では、Application 内のリソース (デプロイ、ポッド、ConfigMap、シークレット) へのアクセスをきめ細かく制御できます。

マルチ環境デプロイに ApplicationSet を使用する: ApplicationSet を使用すると、設定が異なる複数のクラスターまたは名前空間にアプリケーションをデプロイできます。

ライフサイクル管理

アプリケーション同期ポリシー

Argo CD によるアプリケーション同期の方法を制御します。

手動同期: アプリケーションで変更を同期するには、手動承認が必要です。本番稼働環境に推奨されます。

自動同期: Git での変更が検出されると、アプリケーションが自動的に同期します。開発環境とステージング環境でよく使用されます。

自己修復: クラスターに手動で加えられた変更を自動的に元に戻します。クラスターの状態が Git と一致するようになります。

プルーニング: Git から除去されたリソースを自動的に削除します。リソースを削除できるため、使用には注意が必要です。

アプリケーションのヘルス

Argo CD は、アプリケーションのヘルスを継続的にモニタリングします。

同期期間

同期期間を設定して、どのような場合にアプリケーションを同期できるかを制御します。

ウェブフックを設定して同期を高速化する

デフォルトでは、Argo CD は 6 分ごとに Git リポジトリをポーリングして変更がないか検出します。デプロイの応答性を高めるには、変更がプッシュされたらすぐに同期をトリガーするように Git ウェブフックを設定します。

ウェブフックには、次のような利点があります。

ウェブフックエンドポイント

ウェブフック URL はパターン ${serverUrl}/api/webhook に従います。ここでは、Argo CD サーバー URL は serverUrl です。

例えば、Argo CD サーバー URL が https://abc123.eks-capabilities.us-west-2.amazonaws.com の場合、ウェブフック URL は次のようになります。

https://abc123.eks-capabilities.us-west-2.amazonaws.com/api/webhook

Git プロバイダーでウェブフックを設定する

GitHub: リポジトリ設定に、Argo CD ウェブフック URL と共にウェブフックを追加します。コンテンツタイプを application/json に設定し、「Just the push event」を選択します。

GitLab: Project 設定に、Argo CD ウェブフック URL と共にウェブフックを追加します。「Push events」とオプションで「Tag push events」を有効にします。

Bitbucket: リポジトリ設定に、Argo CD ウェブフック URL と共にウェブフックを追加します。トリガーとして「Repository push」を選択します。

CodeCommit: Amazon EventBridge に、CodeCommit リポジトリの状態が変化したらトリガーして、Argo CD ウェブフックエンドポイントに通知を送信するというルールを作成します。

ウェブフック設定の詳細な手順については、「Argo CD ウェブフック設定」を参照してください。

次のステップ