How to Configure an ArgoCD Project

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

Top portion of the configuration

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 for https://g.cth.com/my-project but will not allow https://g.cth.com/my-group/my-project
  • https://g.cth.com/my-group/my-project will only allow https://g.cth.com/my-group/my-project, but not any other projects
  • https://g.cth.com/my-group/* will allow https://g.cth.com/my-group/my-project and any other project in the group, but not any other groups
  • https://g.cth.com/*/* will allow any group beneath https://g.cth.com/, and any project in any of those groups
  • https://g.cth.com/*/*/* will not allow any group beneath https://g.cth.com/, but only those two groups deep
  • https://g.cth.com/** will allow any group or sub group beneath https://g.cth.com/ and any project

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!

2 thoughts on “How to Configure an ArgoCD Project

  1. Pingback: How to Store ArgoCD Projects in YAML - clear the haze

  2. Pingback: ArgoCD Glossary: Simple, And The Best to Get You Deploying

Comments are closed.