Customize Argo CD in Platform Base
All Argo CD options live under argocd in your cluster/config.libsonnet.
Repository credentials
argocd.platformRepoCreds gives Argo CD access to the repository that holds
your cluster configuration. The fields and the way to pass the values are
described in
Install Platform Base.
For an SSH repository, use sshPrivateKey instead of username and
password, render the bootstrap with an SSH repoURL, and add the host key
as described below:
--tla-code dynamicConfig='{ argocd+: { platformRepoCreds+: { enabled: true, sshPrivateKey: importstr "id_ed25519" } } }'
SSH known hosts
argocd.ssh.knownHosts is a list of lines in the known_hosts format. They
are added to the argocd-ssh-known-hosts-cm ConfigMap, next to the hosts Argo
CD already knows:
argocd+: {
ssh+: {
knownHosts: ['git.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...'],
},
},
RBAC
Users who sign in through Keycloak get the role in argocd.rbac.defaultRole,
which is role:readonly. Argo CD reads the groups claim of the token
(argocd.rbac.scopes). Grant more with permissions and bind users or groups
to roles with binds:
argocd+: {
rbac+: {
permissions: [
{
subjects: ['role:deployer'],
resources: ['applications'],
actions: ['get', 'sync'],
objects: ['*/*, allow'],
},
],
binds: [
{ users: ['platform-admins'], subjects: ['role:admin'] },
],
},
},
Each combination of subject, resource, action and object becomes one policy
line p, <subject>, <resource>, <action>, <object>. Argo CD expects the
effect as the last field, so add it to the object as above. Each combination
of user and subject in a bind becomes a line g, <user>, <subject>. A user
can be a group name from the groups claim.
Set permissions and binds as plain fields, without +:, so that your
lists replace the empty entry in the defaults.
Raw ConfigMap data
For anything the typed options do not cover, set the raw data of the Argo CD
ConfigMaps through argocd.configMaps:
argocd+: {
configMaps+: {
'argocd-cm': { data: { 'admin.enabled': 'false', 'timeout.reconciliation': '300s' } },
'argocd-cmd-params-cm': { data: { 'controller.status.processors': '40' } },
'argocd-rbac-cm': { data: { 'policy.matchMode': 'regex' } },
'argocd-tls-certs-cm': { data: { 'git.example.com': importstr 'git-example-com.pem' } },
},
},
- The data is merged over the keys that Platform Base generates from
argocd.sso,argocd.rbac,argocd.sshand the ingress hostname, and your values win. Settingpolicy.csvtherefore replaces the CSV generated fromargocd.rbac, andoidc.configreplaces the generated SSO configuration. - Only these four ConfigMaps are supported. Other names are rejected, so a typo does not go unnoticed.
- Values must be strings. Set a key to
nullto leave it out of the rendered ConfigMap, including a default such asserver.insecureinargocd-cmd-params-cm. The ConfigMaps are applied with server-side apply, which does not delete a key that already exists in the live ConfigMap, so set an explicit value to change an existing key. - The
argocd-cmdata is also applied to the bootstrap render, so the bootstrap and theargocd-configApplication agree, for example on the resource tracking method. - Inline credentials in
dex.configoroidc.configend up in plaintext in the rendered ConfigMap and trigger a warning during rendering. To reference a secret value from a ConfigMap, use Argo CD's$<secret>:<key>syntax. The referenced Secret needs the labelapp.kubernetes.io/part-of: argocd. - Changes to
argocd-cmd-params-cmrequire a restart of the affected Argo CD components.
The ingress talks plain HTTP to argocd-server. Keep server.insecure: TRUE
in argocd-cmd-params-cm unless you also adapt the ingress, otherwise the UI
is unreachable through it.
See the Argo CD documentation for the available keys of
argocd-cm,
argocd-cmd-params-cm,
argocd-rbac-cm and
argocd-tls-certs-cm.
Config Management Plugins
Config Management Plugins run as sidecars of the Argo CD repo server. They are
configured under argocd.configManagementPlugins, keyed by plugin name. The
configuration schema in
vendor/github.com/RocketPadPlatforms/base/config.libsonnet contains a documented helmfile plugin as an example. A plugin needs an
explicit config.image, and a plugin name must be a valid Kubernetes
name (lowercase letters, digits and hyphens).