Enabling OpenShift integrated login is quite simple, but might not be perfectly documented as of today. It is already configured in the templates deployed in the section above. This is just for documentation purposes.

This feature implies changes at several levels:

1. Set an environment variable at the operator level. This will tell the operator to enable Dex server for external authentication. GH Issue, Blog post.

       spec:
         config:
           env:
             - name: DISABLE_DEX
               value: "false"

2. Configure the ArgoCD object to use the DEX Openshift login integration.

       spec:
         dex:
           openShiftOAuth: true

3. Configure the ArgoCD object with the desired RBAC policies. For example, the simples option:

       spec:
         rbac:
           defaultPolicy: 'role:readonly'
           policy: |
             g, system:cluster-admins, role:admin
           scopes: '[groups]'

Apart from using the Openshift integrated login, it is possible to use the built-in admin user. This user has been disabled in the ArgoCD template template/gitops-02-argocd.yaml configuring .spec.disableAdmin to true. Set it to false if you want to use it.

Then, you will be able to login using ArgoCD user / password. Use user admin and obtain the password with the following command:

The current version of Openshift GitOps supports deploying several clusters of ArgoCD in the same Openshift cluster. This feature is essential for organizations that want to implement multi-tenancy at the OCP level. With this feature available, now we have to distribute each namespace among the ArgoCD clusters. This is done using the managed-by label.

Add a label to the namespace where your application is deployed in so that the Argo CD instance in the gitops namespace can manage it:

If you don’t do so, the error message that you will see in the web console when you try to synchronize an application is:

Link to the documentation.

The ArgoCD instance have only privileges in its namespace which is gitops. For creating/updating/listing resources in other namespaces, it’s mandatory to update the RBAC for its Service Account.

This section can be as complex as the security requirements that your organization demands for the ArgoCD deployment. The easiest solution for non-productive environments would be to grant cluster-admin rights to the service account that interacts with the k8s API.

If you prefer to have a per-project tunning, you can use the configuration set in the template template/gitops-03-application-app.yaml, where we provide project admin rights to the same service account. This is also oriented to get a proper multi-tenancy configuration, like in the previous section. Check the template mentioned or use the following command:

Obviously, you can even set a finer tunning by creating a custom Role and RoleBinding to specify the resources that each ArgoCD will be allowed to manage per namespace. This KCS gives you an example of how to configure one of these RoleBindings.

Extra documentation:

• Deep-dive blog post about namespace isolation using the SA RoleBindings.

• Upstream issue regarding permissions for the ArgoCD instance.

The RBAC feature enables restriction of access to Argo CD resources. Argo CD does not have its own user management system and has only one built-in user admin.

The RBAC configuration can be customized using the `ArgoCD.spec.rbac.policy `

/ / TO DO

https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/ https://rtfm.co.ua/en/argocd-users-access-and-rbac/#Projects_and_roles https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#configuring-rbac-with-projects https://github.com/argoproj/argo-cd/blob/master/assets/builtin-policy.csv

https://docs.openshift.com/container-platform/4.8/authentication/understanding-authentication.html

oc adm groups new spring-petclinic-developer oc adm groups new spring-petclinic-admin oc adm groups add-users spring-petclinic-admin alopezme oc adm groups add-users spring-petclinic-developer svidalur