Contents
ArgoCD RBACの重要性とセキュリティ設計の基本原則
GitOps運用において、誤った権限管理は深刻なセキュリティリスクをもたらします。たとえば、誤って全プロジェクトへの変更許可を与えてしまった場合、意図しないアプリケーション破壊やデータ漏洩が発生する可能性があります。このようなリスクを回避し、組織のGitOps体制を信頼性高く運用するには、ロールベースアクセス制御（RBAC）が不可欠です。特に最小権限の原則（Need-to-Know Principle）や責任分離（Separation of Duties）などのセキュリティ設計思想を意識した権限設定が重要になります。以下では、ArgoCDにおけるRBAC設定の基本的な考え方と実装方法について解説します。
argocd-rbac-cm ConfigMapによるポリシー構成
RoleとPolicyの定義例
ArgoCDのアクセス制御は、argocd-rbac-cmというConfigMapを通じて管理されます。このConfigMap内に配置されるPolicy.csvファイルにより、ユーザーまたはグループがどのリソースに対してどのような操作を許可されるかが定義されます。具体的には、p（Policy）とg（Group）の2つの記述形式が基本です。
p(Policy): 明示的な権限付与で、「[ユーザー/グループ]、[リソース]、[操作]、[対象]、[許可/拒否]」という形になります。p, my-team:developer, applications, sync, my-project/*, allowg(Group): グループベースのロール継承を記述し、権限を一括管理できます。g, my-team:admin, role:admin
以下にサンプルを示します：
|
1 2 3 |
p, my-team:developer, applications, sync, my-project/*, allow g, my-team:admin, role:admin |
ClusterRoleとの連携方法
ArgoCDのRBACはKubernetesのClusterRoleと連動させることで、より柔軟な権限管理が可能です。たとえば、以下のようにrole:adminをClusterRoleにマッピングすることで、Kubernetesクラスター全体でのアクセス制御を統合できます。
- ClusterRoleを作成: 既存のClusterRole（例:
cluster-admin）を使用するか、カスタムClusterRoleを定義します。 - ClusterRoleBindingで結びつける: グループやユーザーをClusterRoleに所属させます。
yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: argocd-admin-binding
subjects: - kind: Group
name: my-team:admin
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
このようにすることで、ArgoCDとKubernetesの権限体系を統合し、管理負担を軽減できます。ClusterRoleはクラスター全体に影響を与えるため、慎重な設計が求められます。
外部認証プロバイダーとの連携設定
OIDC/LDAPグループスコープの最適化
ArgoCDはOpenID Connect（OIDC）やLDAPといった外部アカウントプロバイダーと連携させ、ユーザー情報を取得することが可能です。このような場合、groupsスコープを正しく設定することで、組織内の階層構造に応じた権限管理が可能になります。
以下はargocd-rbac-cm ConfigMapのscopesフィールドに設定する例です：
|
1 2 |
scopes: "[groups, email]" |
この設定により、グループ名とユーザーのメールアドレスをArgoCD内で利用可能にし、より細かく権限を制御できます。また、KeycloakやAuth0といったOIDCプロバイダーから取得するグループ情報をもとに、プロジェクト毎のアクセス制限を行うことが可能です。
ユーザー属性による動的権限割り当て
外部プロバイダーからのユーザー属性（メールアドレス、所属部署など）を活用し、動的な権限付与ができます。たとえば、以下のような設定で特定のメールドメインを持つユーザーに限定したアクセスを許可できます。
|
1 2 3 |
g, [email:example.com], role:readonly p, [email:example.com], applications, sync, my-project/demo-app, allow |
このような動的制御により、権限管理が柔軟かつ安全になります。ただし、外部プロバイダーとの連携時に発生するセキュリティギャップを意識し、アクセスログの監査や異常検知機能を併用することが重要です。
ロール継承と明示的アクセス制御
RoleBindingのネスト構造の検討
ArgoCDでは、RoleBindingを使ってロールをユーザーまたはグループに割り当てることができますが、ネストした構造（例: role:adminがrole:developerを含む）を作成する際には注意が必要です。
ネスト構造の課題
- 権限拡散リスク: 高権限ロールが低権限ロールに自動的に付与される可能性がある。
- 管理複雑化: 複数レベルのロール定義により、誤操作や抜け漏れが発生しやすい。
代わりに、明示的かつ単一のRoleBindingで必要最小限の権限を付与することで、管理の透明性と安全性を確保できます。
推奨構成例
|
1 2 3 |
g, my-team:developer, role:developer p, my-team:developer, applications, sync, my-project/*, allow |
このように、ロール名とその対応する権限を1対1で定義することにより、誤ったアクセスが発生しにくい構成になります。
複数プロジェクトへの適切な権限分散
ArgoCDを運用する際には、複数のプロジェクト（Namespace）にまたがる設定が必要になることが多いです。その場合、以下のようにプロジェクトごとにRoleDefinitionを作り、それぞれに適したアクセス制御を行う必要があります。
| プロジェクト | 所属ユーザー / グループ | 権限 |
|---|---|---|
| my-project-a | team:dev | sync, view |
| my-project-b | team:ops | apply, delete |
このようにプロジェクト単位での権限設定により、誤って他チームのリソースを変更するリスクが低減されます。また、RoleDefinitionテンプレートを作成し再利用することで、一貫性のあるセキュリティポリシーを維持できます。
ビルトインAdminユーザーの代替策
サービスアカウントベースの権限管理
ArgoCDではデフォルトで「admin」ユーザーアカウントが存在します。しかし、このアカウントはすべてのリソースに対して変更を許可するため、セキュリティ上非常に危険な存在です。特に、複数人での運用や外部開発者との連携が必要な環境では、誤操作による破壊リスクが高まります。
代替策として、「サービスアカウント（ServiceAccount）」を活用し、権限を制限した上で運用することが推奨されます。たとえば、以下のようにNamespaceごとにServiceAccountを作成し、RoleBindingでアクセス権を付与します：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
apiVersion: v1 kind: ServiceAccount metadata: name: argocd-sa-dev namespace: my-project-a --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: argocd-sa-dev-rolebinding subjects: - kind: ServiceAccount name: argocd-sa-dev roleRef: kind: Role name: argocd-role-dev |
PAM（Pluggable Authentication Modules）によるセキュリティ強化
PAMはArgoCDが提供する、SSHベースの認証プロトコルです。この方式では、ユーザーがArgoCDにアクセスする際、事前にKubernetesクラスターにSSH接続して認証を行います。これにより、ArgoCD側でのパスワード管理やトークン発行の必要がなくなり、セキュリティを強化できます。
PAMの設定例
以下のようにargocd-rbac-cm ConfigMapに定義します：
|
1 2 3 |
# argocd-rbac-cm ConfigMap 内 p, my-team:dev-pam, applications, sync, my-project/*, allow |
このように設定することで、特定のユーザーがSSH経由で認証された場合にのみリソースを操作可能になります。これにより、不正なアクセスや権限逸脱のリスクを大幅に抑えることができます。
多プロジェクト環境での権限分散手法
Namespaceベースのアクセス制御設計
ArgoCDはKubernetesクラスター内のNamespace（プロジェクト）ごとに独立したリソース管理が可能です。この特性を活用し、各Namespaceに対するアクセス制御を明確に分離することで、リスクの集中化や権限の横断的拡散を防ぐことができます。
NamespaceごとのRoleDefinition例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
# my-project-aのRoleDefinition（namespace: my-project-a） kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: argocd-role-dev rules: - apiGroups: [""] resources: ["pods", "services"] verbs: ["get", "list", "watch"] --- # my-project-bのRoleDefinition（namespace: my-project-b） kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: argocd-role-ops rules: - apiGroups: [""] resources: ["deployments", "statefulsets"] verbs: ["get", "list", "watch", "apply"] |
このように、各プロジェクトに合ったロールを設定することで、リソースの管理範囲と権限が明確になります。
プロジェクトごとのRoleDefinitionテンプレート
大規模なGitOps運用環境では、多数のプロジェクトを扱うことが一般的です。それぞれのプロジェクトで個別にRoleDefinitionを作成するのは手間がかかります。そこで、セキュリティポリシーテンプレートを活用し、各プロジェクトへの適用戦略を統一することが推奨されます。
テンプレート例
|
1 2 3 4 5 6 7 8 9 10 |
# 管理者向けRoleDefinition（template: argocd-role-admin.yaml） kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: argocd-role-admin rules: - apiGroups: [""] resources: ["*"] verbs: ["get", "list", "watch", "apply", "delete"] |
このテンプレートを各プロジェクトに適用することで、一貫した権限管理が実現できます。また、テンプレートのバージョン管理とGitOps運用により、セキュリティポリシーの更新も容易になります。