Within ArgoCD, the App Project, aka Project, is the container for controlling permissions around Applications deploying resources into the cluster. Configuring it correctly will lead to a robust, secure deployment environment for leveraging Gitops successfully. Misconfiguring it will lead to frustrated engineers unable to deploy services.
Part 1 – Repositories
Source vs Scoped Repositories
The descriptions for both of these read the same:
Git repositories where application manifests are permitted to be retrieved from
But they do function differently.
Source Repositories
These are the Git repositories which this Project may read. For example, if I shorthand my Gitlab hostname to g.cth.com:
https://g.cth.com/
allows forhttps://
but will not allowg.cth
.com/my-projecthttps://
g.cth
.com/my-group/my-projecthttps://
will only allowg.cth
.com/my-group/my-projecthttps://
, but not any other projectsg.cth
.com/my-group/my-projecthttps://
will allowg.cth
.com/my-group/*https://
and any other project in the group, but not any other groupsg.cth
.com/my-group/my-projecthttps://
will allow any group beneathg.cth
.com/*/*https://
, and any project in any of those groupsg.cth
.com/https://
will not allow any group beneathg.cth
.com/*/*/*https://
, but only those two groups deepg.cth
.com/https://
will allow any group or sub group beneathg.cth
.com/**https://
and any projectg.cth
.com/
Unfortunately, you can create Repositories for a Project which do not match the source repositories configuration.
Scoped Repositories
These are the Git repositories currently assigned to this Project. These come directly from ArgoCD Repositories. There will be issues if a scoped repository does not match a source repository.
application spec is invalid: InvalidSpecError: application repo https://gitlab.clearthehaze.com/examples/hello-world.git is not permitted in project 'example-project'
Part 2 – Restrictions and Allowance
Destinations
This allows you to control the destination for resources deployed within this Project. This may be limiting it to a test cluster, or limiting resources to going to a specific namespace. In my example, I am limiting deployment to the current Kubernetes cluster and only to the namespace example-project
.
Allow and Deny Lists
The next four settings allow you to configure what types of resources are either allowed (limiting anything else) or denied (allowing everything else). This may be applied across the cluster or to specific namespaces. For example, to restrict deploying roles, click the edit button and select Roles in the dropdown for the Kind. Then click Save.
In the example shown above, I’ve also limited access to modifying the ResourceQuota and LimitRange within the namespace. This prevents any application from messing with resource restrictions place on the namespace.
Summary of the Project
The Project is an important component of utilizing ArgoCD. I hope you’ll find this helpful as you embark on applying Gitops!
Pingback: How to Store ArgoCD Projects in YAML - clear the haze
Pingback: ArgoCD Glossary: Simple, And The Best to Get You Deploying