コンテンツにスキップ

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名の重複

単一のClusterでNamespacedスコープのArgoCDを構築している時、RootのApplicationをdefaultというAppProjectに配置すると、この問題が起こる可能性がある。

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

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

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


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で一つのバージョンの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、GitHub、Keycloak、Zitadel、AWS Cognito、Google Cloud Auth) が発行したクライアント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. SSL証明書系ConfigMap

SSL証明書系ConfigMapとは

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

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

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

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


argocd-dex-server-tls

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

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


argocd-repo-server-tls

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

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


argocd-server-tls

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

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


argocd-tls-certs-cm

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

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

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


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