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

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

Argo CD アクセス許可を設定する

Argo CD マネージド機能は、AWS アイデンティティセンターとの統合により認証を実施し、組み込みの RBAC ロールを使用して認可を行います。このトピックでは、ユーザーとチームに対するアクセス許可を設定する方法について説明します。

Argo CD によるアクセス許可の仕組み

Argo CD 機能は、AWS アイデンティティセンターを使用して認証を実施し、組み込みの 3 つの RBAC ロールを使用して認可を行います。

ユーザーが Argo CD にアクセスすると、次のようになります。

組み込みの RBAC ロール

Argo CD 機能には、AWS アイデンティティセンターのユーザーとグループにマッピングする組み込みのロールが 3 つあります。

ADMIN

すべてのアプリケーションと設定にフルアクセスできます。

EDITOR

アプリケーションの作成と変更はできますが、Argo CD 設定を変更することはできません。

VIEWER

アプリケーションに読み取り専用でアクセスする:

ロールマッピングを設定する

機能の作成時や更新時に、AWS アイデンティティセンターのユーザーとグループを Argo CD ロールにマッピングします。

ロールマッピングの例:

{
  "rbacRoleMapping": {		 	 	 
    "ADMIN": ["AdminGroup", "alice@example.com"],
    "EDITOR": ["DeveloperGroup", "DevOpsTeam"],
    "VIEWER": ["ReadOnlyGroup", "bob@example.com"]
  }
}

ロールマッピングを更新する:

aws eksfe update-capability \
  --region us-east-1 \
  --cluster-name cluster \
  --capability-name capname \
  --endpoint "https://eks.ap-northeast-2.amazonaws.com" \
  --role-arn "arn:aws:iam::[.replaceable]111122223333:role/[.replaceable]`EKSCapabilityRole`" \
  --configuration '{
    "argoCd": {
      "rbacRoleMappings": {
        "addOrUpdateRoleMappings": [
          {
            "role": "ADMIN",
            "identities": [
              { "id": "686103e0-f051-7068-b225-e6392b959d9e", "type": "SSO_USER" }
            ]
          }
        ]
      }
    }
  }'

管理者アカウントの使用法

管理者アカウントは、クラスターの登録やリポジトリの設定など、初期セットアップと管理タスク向けに設計されています。

どのような場合に管理者アカウントが適切か:

管理者アカウントのベストプラクティス:

どのような場合に Project ベースのアクセスを使用するか:

本番稼働環境とマルチユーザーシナリオでは、専用の RBAC ロールを AWS アイデンティティセンターグループにマッピングして、Project ベースのアクセスコントロールを使用します。

Project ベースのアクセスコントロール

Argo CD Project (AppProject) を使用すると、チームを対象にアクセスコントロールとリソース分離をきめ細かく設定できます。

Project でできることは以下のとおりです。

チームを分離する Project の例:

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

  # Source restrictions
  sourceRepos:
  - https://github.com/myorg/team-a-apps

  # Destination restrictions
  destinations:
  - namespace: team-a-*
    server: arn:aws:eks:us-west-2:111122223333:cluster/production

  # Resource restrictions
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace
  namespaceResourceWhitelist:
  - group: 'apps'
    kind: Deployment
  - group: ''
    kind: Service
  - group: ''
    kind: ConfigMap

ユーザーを Project に割り当てる:

EDITOR ロールまたは VIEWER ロールが付与されたユーザーを、特定の Project に制限できます。ADMIN ユーザーは、すべての Project にアクセスできます。

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
spec:
  # ... project configuration ...

  # Map Identity Center groups to project roles
  roles:
  - name: developer
    description: Team A developers
    policies:
    - p, proj:team-a:developer, applications, *, team-a/*, allow
    groups:
    - TeamADevelopers

  - name: viewer
    description: Team A viewers
    policies:
    - p, proj:team-a:viewer, applications, get, team-a/*, allow
    groups:
    - TeamAViewers

アクセス許可のよくあるパターン

パターン 1: 管理チームにフルアクセスを付与する

{
  "rbacRoleMapping": {		 	 	 
    "ADMIN": ["PlatformTeam", "SRETeam"]
  }
}

パターン 2: 開発者はデプロイ可能で、それ以外のユーザーは表示可能

{
  "rbacRoleMapping": {		 	 	 
    "ADMIN": ["PlatformTeam"],
    "EDITOR": ["DevelopmentTeam", "DevOpsTeam"],
    "VIEWER": ["AllEmployees"]
  }
}

パターン 3: Project ごとにチーム単位で分離する

{
  "rbacRoleMapping": {		 	 	 
    "ADMIN": ["PlatformTeam"],
    "EDITOR": ["AllDevelopers"]
  }
}

その後、チームに固有の制限とロールのマッピングを施した Project を作成します。

ベストプラクティス

個々のユーザーではなくグループを使用する: AWS アイデンティティセンターグループを個々のユーザーではなく Argo CD ロールにマッピングして、管理を容易にします。

最小特権から開始する: VIEWER アクセスから開始し、必要に応じて EDITOR または ADMIN を付与します。

Project を使用してチームを分離する: チームや環境ごとに AppProject を作成して、境界を確立します。

アイデンティティセンターのフェデレーションを活用する: 社内の ID プロバイダーとフェデレーションするように AWS アイデンティティセンターを設定して、ユーザー管理を一元化します。

アクセスを定期的に見直す: ロールのマッピングと Project の割り当てを定期的に見直して、適切なアクセスレベルを確保します。

クラスターへのアクセスを制限する: Argo CD RBAC は Argo CD リソースとオペレーションへのアクセスを制御しますが、Kubernetes RBAC には対応していないことに注意してください。Argo CD にアクセスできるユーザーは、Argo CD がアクセスできるクラスターにアプリケーションをデプロイできます。Argo CD がアクセスできるクラスターを制限し、Project の宛先制限を使用して、アプリケーションをデプロイできる場所を制御します。

AWS サービスのアクセス許可

Repository リソースを作成することなく Application リソースで AWS サービスを直接使用するには、必要な IAM アクセス許可を機能ロールにアタッチします。

ECR Helm チャート:

{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage"
      ],
      "Resource": "*"
    }
  ]
}

CodeCommit リポジトリ:

{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "codecommit:GitPull"
      ],
      "Resource": "arn:aws:codecommit:region:account-id:repository-name"
    }
  ]
}

CodeConnections (GitHub、GitLab、Bitbucket):

{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "codeconnections:UseConnection"
      ],
      "Resource": "arn:aws:codeconnections:region:account-id:connection/connection-id"
    }
  ]
}

こうした統合の使用の詳細については、「リポジトリアクセスを設定する」を参照してください。

次のステップ