このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

Argo CD Project を操作する

Argo CD Project (AppProject) では、Application を論理的にグループ化して、アクセスコントロールを付与できます。Project は、Application が使用できる Git リポジトリ、ターゲットクラスター、名前空間を定義して、共有 Argo CD インスタンスにマルチテナンシーとセキュリティの境界を確立します。

どのような場合に Project を使用するか

Project を使用すると、以下のことが行えます。

default Project

すべての Argo CD 機能に default Project があり、すべてのリポジトリ、クラスター、名前空間へのアクセスを許可する設定になっています。初期テストには有用ですが、本番稼働に使用する場合は制限を明記した専用の Project を作成します。

default Project の設定とその制限方法の詳細については、Argo CD ドキュメントの「default Project 」を参照してください。

プロジェクトの作成

Project を作成するには、クラスターに AppProject リソースを適用します。

例: チーム固有の Project

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
  namespace: argocd
spec:
  description: Applications for Team A

  # Source repositories this project can deploy from
  sourceRepos:
    - 'https://github.com/my-org/team-a-*'
    - 'https://github.com/my-org/shared-libs'

  # Destination clusters and namespaces
  destinations:
    - name: dev-cluster
      namespace: team-a-dev
    - name: prod-cluster
      namespace: team-a-prod

  # Allowed resource types
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace

  namespaceResourceWhitelist:
    - group: 'apps'
      kind: Deployment
    - group: ''
      kind: Service
    - group: ''
      kind: ConfigMap

Project を適用します。

kubectl apply -f team-a-project.yaml

プロジェクトの設定

ソースリポジトリ

この Project の Application が使用できる Git リポジトリを制御します。

spec:
  sourceRepos:
    - 'https://github.com/my-org/app-*'  # Wildcard pattern
    - 'https://github.com/my-org/infra'  # Specific repo

ワイルドカードと否定パターン (! プレフィックス) を使用すると、特定のリポジトリを許可または拒否できます。詳細については、Argo CD ドキュメントの「Project の管理」を参照してください。

送信先の制限

Application がデプロイできる場所を制限します。

spec:
  destinations:
    - name: prod-cluster  # Specific cluster by name
      namespace: production
    - name: '*'  # Any cluster
      namespace: team-a-*  # Namespace pattern

ワイルドカードと否定パターンを使用して、送信先を制御できます。詳細については、Argo CD ドキュメントの「Project の管理」を参照してください。

リソースの制限

どの Kubernetes リソースタイプをデプロイできるかを制御します。

クラスター範囲のリソース:

spec:
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace
    - group: 'rbac.authorization.k8s.io'
      kind: Role

名前空間範囲のリソース:

spec:
  namespaceResourceWhitelist:
    - group: 'apps'
      kind: Deployment
    - group: ''
      kind: Service
    - group: ''
      kind: ConfigMap
    - group: 's3.services.k8s.aws'
      kind: Bucket

ブラックリストを使用して、特定のリソースを拒否します。

spec:
  namespaceResourceBlacklist:
    - group: ''
      kind: Secret  # Prevent direct Secret creation

Project に Application を割り当てる

Application を作成するときは、spec.project フィールドに Project を指定します。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: team-a  # Assign to team-a project
  source:
    repoURL: https://github.com/my-org/my-app
    path: manifests
  destination:
    name: prod-cluster
    namespace: team-a-prod

Application に Project を指定しないと、default Project が使用されます。

Project のロールと RBAC

Project では、カスタムロールを定義して、アクセスコントロールをきめ細かく設定できます。機能設定で Project のロールを AWS アイデンティティセンターのユーザーとグループにマッピングすると、アプリケーションを同期、更新、または削除できるユーザーを制御できます。

例: Project に開発者ロールと管理者ロールを付与する

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
  namespace: argocd
spec:
  sourceRepos:
    - '*'
  destinations:
    - name: '*'
      namespace: 'team-a-*'

  roles:
    - name: developer
      description: Developers can sync applications
      policies:
        - p, proj:team-a:developer, applications, sync, team-a/*, allow
        - p, proj:team-a:developer, applications, get, team-a/*, allow
      groups:
        - team-a-developers

    - name: admin
      description: Admins have full access
      policies:
        - p, proj:team-a:admin, applications, *, team-a/*, allow
      groups:
        - team-a-admins

Project のロール、CI/CD パイプラインの JWT トークン、および RBAC 設定の詳細については、Argo CD ドキュメントの「Project のロール」を参照してください。

一般的なパターン

環境ベースの Project

環境ごとに Project を作成します。

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production
  namespace: argocd
spec:
  sourceRepos:
    - 'https://github.com/my-org/*'
  destinations:
    - name: prod-cluster
      namespace: '*'
  # Strict resource controls for production
  clusterResourceWhitelist: []
  namespaceResourceWhitelist:
    - group: 'apps'
      kind: Deployment
    - group: ''
      kind: Service

チームベースの Project

専用の Project でチームを分離します。

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: platform-team
  namespace: argocd
spec:
  sourceRepos:
    - 'https://github.com/my-org/platform-*'
  destinations:
    - name: '*'
      namespace: 'platform-*'
  # Platform team can manage cluster resources
  clusterResourceWhitelist:
    - group: '*'
      kind: '*'

マルチクラスターの Project

ポリシーに一貫性のある複数のクラスターにデプロイします。

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: global-app
  namespace: argocd
spec:
  sourceRepos:
    - 'https://github.com/my-org/global-app'
  destinations:
    - name: us-west-cluster
      namespace: app
    - name: eu-west-cluster
      namespace: app
    - name: ap-south-cluster
      namespace: app

ベストプラクティス

制限のある Project から始める: 最初から幅広いアクセスを付与するのではなく、絞り込んだアクセス許可から始め、必要に応じて拡張します。

名前空間パターンを使用する: 名前空間の制限 (team-a-* など) にワイルドカードを活用して、境界を維持しながら柔軟性を確保します。

本番稼働用の Project を分離する: 本番稼働専用の Project を使用する場合は、制御を厳格にし、手動同期ポリシーを実施します。

Project の目的を文書化する: description フィールドを使用して、各 Project の目的と誰が使用すべきかを説明します。

Project のアクセス許可を定期的に見直す: Project を定期的に監査して、制限がチームのニーズとセキュリティ要件に沿っていることを確認します。

その他のリソース