Bootstrapping Argo CD


Initial installation of the Rubin Science Platform is done using Argo CD and a static password for the admin account. You can then log on to the admin account using that password to manage the resulting environment. The password is available as the admin.plaintext_password key in Vault secret for the argocd application.

As part of bootstrapping a new environment, you should also configure per-user authentication. To do this, follow the instructions in Argo CD authentication.

Once the environment has been installed, switch to using per-user authentication for all routine operations, and save the admin account only for emergency situations, such as some problem that breaks per-user authentication.

Access control

When you followed the instructions in Argo CD authentication, you set up role:admin access to Argo CD for a group or list of users.

If the only people who need to manage applications in the environment are those administrators, you don’t need to do any further configuration. If other people need to view or modify some Argo CD applications, you will need to configure up Argo CD RBAC (role-based access control).

Built-in roles

Argo CD supports two built-in roles, the first of which you configured when following the steps in Argo CD authentication:


Full read/write access to everything managed by Argo CD.


Read-only access to everything, but no write access.

You can add additional users or groups to these roles using g lines in the"policy.csv" key in values-environment.yaml.

Custom roles

If you want to give some users access to change some Argo CD applications but not others, you will need to define a custom role and then assign it to users or groups.

All applications in Argo CD are assigned to a project. The list of projects are the top-level divisions in Applications. The primary purpose of these projects is for access control. The infrastructure project, in particular, holds the critical Phalanx infrastructure that application developers should not need to change and that runs the highest risk of breaking the environment in a way that would require Kubernetes-level intervention.

A common RBAC pattern is therefore to set up a role:developer role that has write access to all applications except those in the infrastructure project. To create this role, add the following lines to the top of the policy.csv in values-environment.yaml for your environment:

p, role:developer, applications, *, */*, allow
p, role:developer, applications, get, infrastructure/*, allow
p, role:developer, applications, create, infrastructure/*, deny
p, role:developer, applications, update, infrastructure/*, deny
p, role:developer, applications, delete, infrastructure/*, deny
p, role:developer, applications, sync, infrastructure/*, deny
p, role:developer, applications, override, infrastructure/*, deny
p, role:developer, applications, action/*, infrastructure/*, deny

You can then assign role:developer to users or groups in exactly the same way as the built-in role:admin and role:readonly roles.

This same approach can be used to restrict access to other Argo CD projects (such as telescope). Or, alternately, you can grant a role write access to only one Argo CD project and read access to everything else with a role definition like:

p, role:rsp, applications, get, */*, allow
p, role:rsp, applications, *, rsp/*, allow

More complicated rules are possible. See the Argo CD RBAC documentation for the details.

TLS configuration

By default, Argo CD manages the TLS configuration for the entirety of the Science Platform. This assumes the Let’s Encrypt approach to obtaining TLS certificates, and the default TLS configuration requires the cert-manager cluster issuer be set up. See Cert-manager architecture and notes for more information.

If you instead are using a commercial certificate and configuring ingress-nginx to use it, you need to disable the TLS configuration for Squareone. Do that with the following in values-environment.yaml in /applications/argocd:

      tls: false