コンテンツにスキップ

ConfigMap系＠リソース定義

はじめに

本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。


01. 専用ConfigMap

ArgoCD の各コンポーネントの機密でない変数やファイルを管理する。

ConfigMap では、.metadata.labels キー配下に、必ず app.kubernetes.io/part-of: argocd キーを割り当てる必要がある。


02. argocd-cm (必須)

argocd-cmとは

ArgoCD の各コンポーネントで共通する値を設定する。


exec

▼ execとは

ArgoCD の Exec 機能を設定する。

▼ exec.enabled

Exec 機能を有効化する。

kubectl exec コマンドのようにして、ArgoCD のダッシュボード上からコンテナにログインできる。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  exec.enabled: "true"

argocd-server に紐づける ClusterRole では、Pod の exec リソースと create アクションを許可する必要がある。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  namespace: argocd
  name: argocd-server
  labels:
    app.kubernetes.io/part-of: argocd
rules:
  - apiGroups:
      - ""
    resources:
      - pods/exec
    verbs:
      - create

▼ exec.enabled

すべてのコンテナに Exec できるわけではなく、ArgoCD がサポートしているシェルでログインできるコンテナにのみ、Exec が可能である。

ログイン時に使用できるシェルを設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  exec.shells: bash,sh,powershell,cmd


application.instanceLabelKey

▼ application.instanceLabelKeyとは

Kubernetes リソースや子 Application が親 Application を識別するためのラベルのキー名を設定する。

デフォルトは app.kubernetes.io/instance キーであり、コンフリクトしやすいキー名なため、変更したほうがよい。

ラベルのキー名は 1 個しか設定できない。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  application.instanceLabelKey: argocd.argoproj.io/instance

▼ ラベル挿入のタイミング

argocd.argoproj.io/instance ラベルの挿入は、application-controller が実行する。

そのため挿入のタイミングは、マニフェスト作成のタイミングではなく、Sync の直前である。

ConfigMap や Secret のファイル変更に合わせてチェックサム値を更新するようなロジックがチャートあったとしても、repo-server がマニフェスト作成時に argocd.argoproj.io/instance ラベルを挿入するわけではないので、チェックサム値は変更にならない。

なお、CRD には挿入しない仕様になっている。

▼ RootのApplication名の重複

単一の Kubernetes Cluster で Namespaced スコープの ArgoCD を構築しているとき、Root の Application を default という AppProject へ配置すると、この問題が起こりうる。

default の AppProject に所属した Application は、Namespaced スコープの application-controller であって、他の Namespace も見てしまうようである。

Root の Application 名が重複している場合、たとえ Namespace が異なっていても、Namespace 間で Root の Application を共有してしまう。

ちなみに、Cluster スコープの ArgoCD に限り、.spec.sourceNamespaces キーを使用して、この重複を許可できる。


application.resourceTrackingMethod

▼ application.resourceTrackingMethodとは

トラッキング ID を有効化する。

  • label (argocd.argoproj.io/instance ラベルを指す)
  • annotation+label
  • annotation
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  application.resourceTrackingMethod: annotation


globalProjects

▼ globalProjectsとは

グローバルスコープを持つ親 AppProject と、これの設定値を継承させる子 AppProject を指定する。

labelSelector キーで、子 Project の条件を設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  globalProjects: |
    - projectName: foo-global-project
      labelSelector:
        matchExpressions:
          - key: opt
            operator: In
            values:
              - prd

# グローバルスコープを持つ親AppProject
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: foo-global-project
spec: ...


kustomize.buildOptions

▼ kustomize.buildOptionsとは

Kustomize の実行時に、コマンドに渡すオプションを設定する。

特に、Kustomize のプラグイン (例：KSOPS など) を使用する場合、--enable-alpha-plugins オプションと --enable-exec オプションを有効化する必要がある。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  kustomize.buildOptions: --enable-alpha-plugins --enable-exec

なお、kustomize.path.<バージョン> オプションを使用している場合、kustomize.buildOptions.<バージョン> オプションの使用が必須であり、バージョンごとにオプションを設定できる。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  kustomize.buildOptions.v1.0.0: --enable-alpha-plugins --enable-exec
  kustomize.buildOptions.v2.0.0: --enable-alpha-plugins --enable-exec


kustomize.path.<バージョン>

▼ kustomize.path.<バージョン>とは

デフォルトの Kustomize のバージョン以外のものも使用したい場合、そののバージョンと、バイナリファイルの置き場所を設定する。

ArgoCD で 1 つのバージョンの Kustomize しか使用しない場合、kustomize.path.<バージョン> で /usr/local/bin/kustomize を指定する。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  kustomize.path.v1.0.0: /usr/local/bin/kustomize

複数のバージョンの Kustomize を使用できる。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  kustomize.path.v1.0.0: /usr/local/bin/kustomize_1_0_0
  kustomize.path.v2.0.0: /usr/local/bin/kustomize_2_0_0

▼ 各ApplicationでKustomizeを使用する

Application の .spec.kustomize.version キーで、使用する Kustomize のバージョンを指定する。

各 Application で異なるバージョンの Kustomize を指定できる。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: foo-application
  namespace: argocd
spec:
  repoURL: https://github.com/hiroki-hasegawa/foo-manifests.git
  targetRevision: main
  path: .
  kustomize:
    version: v1.0.0


oidc.config

▼ oidc.configとは

OIDC を使用して、ArgoCD へログインできるようにする。

▼ 委譲先Webサイトに直接的に接続する場合

ArgoCD から認証フェーズの委譲先の ID プロバイダーに情報を直接的に接続する。

OIDC の ID プロバイダー (例：Auth0、AWS Cognito、GitHub、Google Cloud Auth、Keycloak、Zitadel) が発行したクライアント ID やクライアントシークレットを設定する。

ここでは、プライベートなマニフェストリポジトリが異なるレジストリにあるとしており、複数の Secret が必要になる。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
data:
  admin.enabled: "true"

  # OIDCに必要なIDやトークンを設定する
  oidc.config: |
    connectors:
      - type: github
        id: github
        name: GitHub SSO
        config:
          clientID: *****
          clientSecret: *****
        # dex-serverが認可レスポンスによるリダイレクトを受信するURLを設定する
        redirectURI: https://<ArgoCDのドメイン>/api/dex/callback

  # ArgoCDのダッシュボードのNode外公開URLを設定する
  # 開発環境では、https://127.0.0.1:8080
  url: <URL>

▼ Dexを介して委譲先Webサイトに接続する場合

ArgoCD から認証フェーズの委譲先の ID プロバイダーに直接的に接続するのではなく、ハブとしての Dex を使用する。

Dex は dex-server コンテナとして稼働させる。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
data:
  admin.enabled: "true"

  # 必要なIDやトークンを設定する。
  dex.config: |
    connectors:
      - type: github
        id: github
        name: GitHub SSO
        config:
          clientID: *****
          clientSecret: *****
        # dex-serverが認可レスポンスによるリダイレクトを受信するURLを設定する
        redirectURI: https://<ArgoCDのドメイン>/api/dex/callback

  # ArgoCDのダッシュボードのNode外公開URLを設定する。
  # 開発環境では、https://127.0.0.1:8080
  url: <URL>


repositories

▼ repositoriesとは

ConfigMap でリポジトリの URL を管理する方法は、将来的に廃止される予定である。


resource.customizations.ignoreDifferences.all

▼ resource.customizations.ignoreDifferences.allとは

ArgoCD 全体で .spec.ignoreDifferences キーと同じ機能を有効化する。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  resource.customizations.ignoreDifferences.all: |
    jsonPointers:
      # .spec.replicasキー (インスタンス数) の設定値の変化を無視する。
      - /spec/replicas
    jqPathExpressions:
      # .spec.metrics (ターゲット対象のメトリクス) の自動整形を無視する。
      - /spec/metrics


03. argocd-cmd-params-cm

argocd-cmd-params-cmとは

ArgoCD の各コンポーネント (application-controller、dex-server、redis-server、repo-server) の起動コマンドに渡すオプションを設定する。


複数コンポーネント

複数コンポーネントの起動コマンドのオプションを設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  # application-controllerとargocd-server
  # Applicationの作成を許可したいNamespaceを設定する
  application.namespaces: foo-application-ns


application-controller

application-controller の起動コマンドのオプションを設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  # Applicationの作成を許可したいNamespaceを設定する
  application.namespaces: foo
  controller.log.format: text
  controller.log.level: warn
  controller.operation.processors: "10"
  controller.repo.server.timeout.seconds: "60"
  controller.self.heal.timeout.seconds: "5"
  controller.status.processors: "20"
  otlp.address: ""


redis-server

redis-server の起動コマンドのオプションを設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  redis.server: argocd-redis:6379


repo-server

repo-server の起動コマンドのオプションを設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  repo.server: argocd-repo-server:8081
  reposerver.log.format: text
  reposerver.log.level: warn
  reposerver.parallelism.limit: "0"


argocd-server

argocd-server の起動コマンドのオプションを設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  server.basehref: /
  server.dex.server: https://argocd-dex-server:5556
  server.dex.server.strict.tls: "false"
  server.disable.auth: "false"
  server.enable.gzip: "false"
  # ロードバランサーで、リクエストをHTTPでフォワーディングするように設定している場合、argocd-serverでHTTPリクエストの受信を許可する
  server.insecure: "true"
  server.log.format: text
  server.log.level: warn
  server.repo.server.strict.tls: "false"
  server.rootpath: ""
  server.staticassets: /shared/app
  server.x.frame.options: sameorigin


04. argocd-rbac-cm

ArgoCD を構成する Kubernetes リソースにリクエストを送信するための認可スコープを紐付ける。


認可スコープの設定

▼ 記法

Casbin の記法を使用して、ロールと認可スコープを定義しつつ、これをグループ名に紐付ける。

readonly と admin というロールは、デフォルトで定義済みである。

記号 項目 説明
p (パーミッション) p, <ロール名> <Kubernetesリソースの種類> <アクション名> <AppProject名>/<ApplicationのNamespace名>/<Application名> ロールとArgoCD系リソースの認可スコープを定義する。代わりに、RoleやClusterRoleでも定義できる。
g (グループ) g, <グループ名> <ロール名> グループにロールを紐付ける。


ArgoCDで認証する場合

ロールに付与するポリシーの認可スコープは、AppProject 単位にするとよい。

AppProject に所属する ArgoCD 系リソースのみへのアクセスを許可すれば、結果として特定の Cluster へのデプロイのみを許可したことになる。

＊実装例＊

管理チーム (app、infra) 単位で AppProject を作成したうえで、AppProject に所属する ArgoCD 系リソースのみに認可スコープを持つロールを定義する。

これにより、その管理チームに所属するエンジニアしか Sync できなくなる。

  • app ロールに、app の AppProject に所属する ArgoCD 系リソースのみを操作できる認可スコープ
  • infra ロールに、infra のみを操作できる認可スコープ
  • maintainer ロールに、app と infra の両方を操作できる認可スコープ
  • 認証グループに該当する認可ロールがなければ、readonly になる。
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  # デフォルトのロール
  policy.default: role:readonly
  policy.csv: |
    # ロールと認可スコープを定義する
    p, role:app, *, *, app/*, allow
    p, role:infra, *, *, infra/*, allow
    p, role:maintainer, *, *, app/*, allow
    p, role:maintainer, *, *, infra/*, allow

    # グループにロールを紐付ける。
    g, app-team, role:app
    g, infra-team, role:infra
    g, admin, role:maintainer
  scopes: "[groups]"

＊実装例＊

実行環境 (dev、prd) 別に AppProject を作成したうえで、AppProject に所属する ArgoCD 系リソースのみに認可スコープを持つロールを定義する。

  • developer ロールに、開発環境の AppProject 内に所属する ArgoCD 系リソースのみを操作できる認可スコープ
  • maintainer ロールに、開発環境と本番環境の両方を操作できる認可スコープ
  • 認証グループに該当する認可ロールがなければ、readonly になる。
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  # デフォルトのロール
  policy.default: role:readonly
  policy.csv: |
    # ロールと認可スコープを定義する
    p, role:developer, *, *, dev/*, allow
    p, role:maintainer, *, *, dev/*, allow
    p, role:maintainer, *, *, prd/*, allow

    # グループにロールを紐付ける
    g, developers, role:developer
    g, maintainers, role:maintainer
  scopes: "[groups]"


ArgoCDの認証をIDプロバイダーに委譲する場合 (SSOの場合)

▼ IDプロバイダーのチームに紐付ける場合

ID プロバイダーに委譲する場合、グループ名は ID プロバイダーで認証されたものにする必要がある。

＊実装例＊

ID プロバイダー側で、チームによる認証グループがすでに存在しているとする。

以下のように、ロールと認可スコープを紐付ける。

  • app ロールに、app の AppProject に所属する ArgoCD 系リソースのみを操作できる認可スコープ
  • infra ロールに、infra のみを操作できる認可スコープ
  • maintainer ロールに、app と infra の両方を操作できる認可スコープ
  • 認証グループに該当する認可ロールがなければ、readonly になる。
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  # デフォルトのロール
  policy.default: role:readonly
  policy.csv: |
    # ロールとArgoCD系リソースの認可スコープを定義する
    p, role:app, *, *, app/*, allow
    p, role:infra, *, *, infra/*, allow
    p, role:maintainer, *, *, app/*, allow
    p, role:maintainer, *, *, infra/*, allow

    # IDプロバイダーで認証されたグループにロールを紐付ける
    g, example-org.github.com:app-team, role:app
    g, example-org.github.com:infra-team, role:infra
    g, example-org.github.com:maintainer, role:maintainer
  scopes: "[groups]"

＊実装例＊

ID プロバイダー側で、チームによる認証グループがすでに存在しているとする。

実行環境 (dev-*、prd-*) 別に AppProject を作成したうえで、AppProject に所属する ArgoCD 系リソースのみに認可スコープを持つロールを定義する。

以下のように、ロールと認可スコープを紐付ける。

  • app ロールに、dev-app の AppProject に所属する ArgoCD 系リソースのみを操作できる認可スコープ
  • infra ロールに、dev-infra のみを操作できる認可スコープ
  • maintainer ロールに、dev-app と dev-infra の両方を操作できる認可スコープ
  • 認証グループに該当する認可ロールがなければ、readonly になる。
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  # デフォルトのロール
  policy.default: role:readonly
  policy.csv: |
    # ロールとArgoCD系リソースの認可スコープを定義する
    p, role:app, *, *, dev-app/*, allow
    p, role:infra, *, *, dev-infra/*, allow
    p, role:maintainer, *, *, dev-app/*, allow
    p, role:maintainer, *, *, dev-infra/*, allow

    # IDプロバイダーで認証されたグループにロールを紐付ける
    g, example-org.github.com:app-team, role:app
    g, example-org.github.com:infra-team, role:infra
    g, example-org.github.com:maintainer, role:maintainer
  scopes: "[groups]"

▼ IDプロバイダーのメールアドレスに紐付ける場合

ID プロバイダー側で、メールアドレスによる認証グループがすでに存在しているとする。

以下のように、ロールと認可スコープを紐付ける。

  • app ロールに、app の AppProject に所属する ArgoCD 系リソースのみを操作できる認可スコープ
  • infra ロールに、infra のみを操作できる認可スコープ
  • maintainer ロールに、app と infra の両方を操作できる認可スコープ
  • 認証グループに該当する認可ロールがなければ、readonly になる。
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  # デフォルトのロール
  policy.default: role:readonly
  policy.csv: |
    # ロールとArgoCD系リソースの認可スコープを定義する
    p, role:app, *, *, app/*, allow
    p, role:infra, *, *, infra/*, allow
    p, role:maintainer, *, *, app/*, allow
    p, role:maintainer, *, *, infra/*, allow

    # IDプロバイダーで認証されたグループにロールを紐付ける
    g, app-team@gmail.com, role:app
    g, infra-team@gmail.com, role:infra
    g, maintainer@gmail.com, role:maintainer
  scopes: "[email]"


05. サーバー証明書系ConfigMap

サーバー証明書系ConfigMapとは

argocd-server、repo-server、dex-server、は HTTPS リクエストを受信できる。

これらのコンポーネントに HTTPS リクエストを送信する場合、ConfigMap 上のサーバー証明書をクライアント側のコンテナにマウントする必要がある。

反対に HTTP リクエストを送信する場合は、この ConfigMap が不要である。

ConfigMap 上のサーバー証明書の代わりに、ArgoCD 外のサーバー証明書 (例：Cert Manager) を使用してもよい。


argocd-dex-server-tls

argocd-server は dex-server に対して HTTPS リクエストを送信する。

この ConfigMap は、そのためのサーバー証明書を管理する。


argocd-repo-server-tls

application-controller、argocd-server、は repo-server に対して HTTPS リクエストを送信する。

この ConfigMap は、そのためのサーバー証明書を管理する。


argocd-server-tls

クライアントは argocd-server に対して HTTPS リクエストを送信する。

この ConfigMap は、そのためのサーバー証明書を管理する。


argocd-tls-certs-cm

ArgoCD は、ArgoCD の外 (特にリポジトリ) に HTTPS リクエストを送信する。

ArgoCD では、コンテナイメージの /etc/ssl ディレクトリにデフォルトのサーバー証明書が配置されているが、ユーザー定義のサーバー証明書を使用したい場合がある。

この ConfigMap は、そのためのユーザー定義のサーバー証明書を管理する。


06. argocd-ssh-known-hosts-cm

SSH 公開鍵認証でリポジトリに接続してポーリングする場合、argocd-server で必要な known_hosts ファイルを設定する。

known_hosts ファイルには、SSH プロコトルに必要なホスト名や秘密鍵を設定する。

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: argocd-ssh-known-hosts-cm
  labels:
    app.kubernetes.io/part-of: argocd
data:
  ssh_known_hosts: |
    bitbucket.org ssh-rsa AAAAB ...
    github.com ecdsa-sha2-nistp256 AAAAE ...
    github.com ssh-ed25519 AAAAC ...
    github.com ssh-rsa AAAAB ...
    gitlab.com ecdsa-sha2-nistp256 AAAAE ...
    gitlab.com ssh-ed25519 AAAAC ...
    gitlab.com ssh-rsa AAAAB ...
    ssh.dev.azure.com ssh-rsa AAAAB ...
    vs-ssh.visualstudio.com ssh-rsa AAAAB ...


07. 環境変数

application-controller

▼ ARGOCD_CONTROLLER_REPLICAS

application-controller のレプリカ数を設定する。

これを設定しないと、application-controller を冗長化しても、処理が片方のレプリカに偏ってしまう。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: argocd-application-controller
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: argocd-application-controller
          env:
            - name: ARGOCD_CONTROLLER_REPLICAS
              value: 2


argocd-server

▼ ARGOCD_API_SERVER_REPLICAS

argocd-server のレプリカ数を設定する。

これを設定しないと、argocd-server を冗長化しても、処理が片方のレプリカに偏ってしまう。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-server
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: argocd-server
          env:
            - name: ARGOCD_API_SERVER_REPLICAS
              value: 3