How to use Github as a SSO of ArgoCD in 3 steps
Imagine having ArgoCD installed as your GitOps source for your cluster, having your dashboard exposed on the web, and wanting to give access to your developers. You think about the best way to do it. You have to create users and groups, attach the users to the groups and permissions for those groups.
We can optimize this process by utilizing the integrations that ArgoCD provides. By using the users and groups of your Github organization, you can facilitate the setup, focusing only on creating the necessary permissions. Also, with this strategy, we can be sure that our ArgoCD dashboard will be safe, easy to manage, and under control!
So, let's get down to work and see how it is implemented.
Step 1. Register a new OAuth user in your GitHub organization
First, we must register a new Oauth application. For this, we go to the configuration of our GitHub organization, and in the list on the left, if we go to the bottom, we will find the developer options, among them the OAuth ones.
In this window, we will see the applications we have already created (if we have any) and the button to create a new one. Click on this last one.
Here, we must complete the data with a representative name for the OAuth application, a URL, which must be the URL of our Argo dashboard, for example, argocd.example.com, and finally, a callback URL, which is an endpoint that argocd already has, which is /api/dex/callback.
Click on register application.
This will return a client ID and generate a secret ID. You must save these for the next step!
Step 2. Integrate Github Login in ArgoCD
For this step, we must modify one of the resources that Argocd creates for its installation in the Kubernetes cluster. It is a config map called argocd-cm, located in the namespace where argocd was installed. In this example, Argo was installed in the "argocd" namespace. We run the following command:
kubectl edit configmap argocd-cm -n argocd
Inside this file, we must locate ourselves inside the "data" section there, we will add the following
data:
dex.config: |
connectors:
- type: github
id: github
name: GitHub
config:
clientID: <CLIENTID>
clientSecret:<CLIENTSECRET>
orgs:
- name: <ORG_NAME>
You must change the URL and organization name to yours and use the client ID and client secret copied from the previous step.
Then, save the changes, and they will take effect automatically. If you log in again to your dashboard, you should see the following.
Optional: It is recommended to disable the Admin user as now the users will be managed through GitHub.
Step 3. Create permissions
For this last step, only the permissions to each group remain to be assigned. To do this, we must know which resources and actions Argo allows us to perform.
Resources: clusters, projects, applications, applicationsets, repositories, certificates, accounts, gpgkeys, logs, exec, extensions.
Actions: get, create, update, delete, sync, override, action/<group/kind/action-name>.
It is also necessary to know that Argo is managed with a role modality. We create policies for a role and attach that role to a GitHub group. A group can have multiple roles since Argo is managed in a deny all permissions until told otherwise mode. Having more roles includes adding more permissions to a group. Argo also defaults to two roles for use: admin and readonly.
Let's see how to create permissions!
As in the previous step, we must modify a config map; Argo creates it in your installation. The name of the config map is "argocd-rbac-cm", and to edit it, we execute the following command.
kubectl edit configmap argocd-cm -n argocd
All the policy configurations are placed under the data section.
data:
policy.csv: |
For all resources, we use the following format
p, <role/user/group>, <resource>, <action>, <object>
And only for the applications we will use this other one
p, <role/user/group>, <resource>, <action>, <appproject>/<object>
Let's imagine we want to create a user with permissions to get, sync and update any application. We will do it in the following way:
p, role:app-developer-role, applications, get, /, allow
p, role:app-developer-role, applications, applications, sync, /, allow
p, role:app-developer-role, applications, update, /, allow
With this, we create a new role called app-developer-role (you can give it any name) with the permissions we want for all the applications. How do I associate this with a GitHub group? Very easy! For this, Argo has this other format.
g, <ORG_NAME>:<GIT_GROUP>, role:app-developer-role
When a user logs in, GitHub reads your associated groups and automatically associates the role to you!
An example of what complex permissions would look like would be as follows.
data:
policy.csv: |│
p, role:default, projects, get, *, allow
p, role:default, applications, get, /, allow
p, role:default, logs, get, *, allow
p, role:powerdevelopers, projects, get, *, allow
p, role:powerdevelopers, projects, create, *, allow
p, role:powerdevelopers, projects, sync, *, allow
p, role:powerdevelopers, applications, get, /, allow
p, role:powerdevelopers, applications, create, /, allow
p, role:powerdevelopers, applications, update, /, allow
p, role:powerdevelopers, applications, sync, /, allow
p, role:powerdevelopers, applications, delete, /, allow
p, role:powerdevelopers, applications, override, /, allow
p, role:powerdevelopers, repositories, get, *, allow
p, role:powerdevelopers, repositories, create, *, allow
p, role:powerdevelopers, repositories, update, *, allow
p, role:powerdevelopers, repositories, delete, *, allow
p, role:powerdevelopers, certificates, get, *, allow
p, role:powerdevelopers, certificates, create, *, allow
p, role:powerdevelopers, certificates, update, *, allow
p, role:powerdevelopers, certificates, delete, *, allow
p, role:developers, project, sync, *, allow
p, role:developers, applications, update, /, allow
p, role:developers, applications, sync, /, allow
p, role:developers, applications, override, /, allow
g, ORG:Developers, role:developers
g, ORG:PowerDev, role:powerdevelopers
g, ORG:Admins, role:admin
And that's it. Now you have your Argocd and Github connected! It’s your turn to set to your users a permission list!
Sources:
Fabricio Blas
Cloud Engineer
Teracloud
