Enable your Developers to Deploy Applications Through ArgoCD – OpenShift GitOps
Satisfying Developer Requests
Our customer recently requested that we simply grant access to the developers in order for them to manage the appropriate projects in OpenShift. Developers wanted to construct applications on OpenShift without consulting administrators for access to ArgoCD/OpenShift GitOps at the same time. This has become increasingly important in non-production settings. Should a developer team wait for an administrator to adjust settings before starting to construct a new application on OpenShift after going through the trouble of seeking budget, time, and resources?
In this post, we’ll look at how administrators may use OpenShift GitOps to create an environment that encourages developers to manage their own applications and content. This will speed up the development process by giving developers the freedom to deploy resources as frequently as they need them.
Recipe for success
Install GitOps. To execute this properly, you’ll need a basic deployment of GitOps in an OpenShift environment. Installing OpenShift GitOps – GitOps | CI/CD has further information on how to do this. The following custom resource definitions are installed, two of which are used in this example:
-bash $ oc get crd -o custom-columns=NAME:.metadata.name | grep argo applications.argoproj.io applicationsets.argoproj.io appprojects.argoproj.io argocds.argoproj.io
After that, double-check that your GitOps administrator team has been granted administrator access. We have two teams in our example: one is a platform admin team with full access to manage Argo, while the other is a read-only team. As an example, consider the following:
apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: finalizers: - argoproj.io/finalizer name: openshift-gitops namespace: openshift-gitops ownerReferences: - apiVersion: pipelines.openshift.io/v1alpha1 blockOwnerDeletion: true controller: true kind: GitopsService name: cluster spec: *********** rbac: defaultPolicy: "" policy: | p, role:platform-team-admin, applications, *, */*, allow p, role:platform-team-admin, *, *, *, allow p, role:platform-readonly, applications, get, */*, allow p, role:platform-readonly, repositories, get, *, allow p, role:platform-readonly, logs, get, *, allow p, role:platform-readonly, projects, get, *, allow p, role:platform-readonly, clusters, get, *, allow p, role:platform-readonly, accounts, get, *, allow p, role:platform-readonly, certificates, get, *, allow p, role:platform-readonly, gpgkeys, get, *, allow g, PlatformAdmins, role:platform-team-admin g, PlatformReaders, role:platform-readonly scopes: '[accounts,groups]' ***********
A list of custom resources has been imported into the OpenShift Cluster after the deployment of OpenShift GitOps. These are the resources that might be developed if a new team needs access to OpenShift GitOps in order to build OpenShift applications. The AppProject is the most important resource to construct. This is an example of GitOps’ ability to establish multi-tenanted environments.
This might be a good place to start for a “real-life” example of using GitOps to communicate with several namespaces in an OpenShift cluster:
kind: AppProject metadata: name: teamproj namespace: openshift-gitops spec: clusterResourceWhitelist: - group: '*' kind: '*' description: teamproj project destinations: - namespace: teamproj-dev server: https://kubernetes.default.svc - namespace: teamproj-uat server: https://kubernetes.default.svc - namespace: teamproj-pp server: https://kubernetes.default.svc namespaceResourceBlacklist: - group: '*' kind: NetworkPolicy - group: '*' kind: ResourceQuota - group: '*' kind: LimitRange roles: - description: Admin group for teamproj groups: - teamadmins name: team-admins policies: - p, proj:teamproj:team-admins, applications, *, teamproj/*, allow - p, proj:teamproj:team-admins, repositories, *, teamproj/*, allow - description: Readonly group for teamproj groups: - teamreaders name: teama-readers policies: - p, proj:teamproj:team-readers, applications, get, teamproj/*, allow - p, proj:teamproj:team-readers, repositories, get, teamproj
We’ve tagged the namespaces stated above with the following to allow OpenShift GitOps to handle them:
oc label namespace teamproj-dev argocd.argoproj.io/managed-by=openshift-gitops
The scoped resources for the project generated in GitOps are shown above. In most cases, an ArgoCD administrator launches a project and specifies which clusters and Git repositories it will use. For ever-changing teams and clusters, this is impossible. It causes issues in situations where a developer wants to add a repository or cluster after the project has been created. The project definition above demonstrates a dependable method of providing a self-service specification for allowing developers to add their own repositories and applications to the GitOps area.
The above description prevents modifications to the OpenShift projects’ NetworkPolicy, ResourceQuota, and LimitRange resources, which the GitOps project can deploy to. If the OpenShift RBAC fits the limitations, this is a good technique to ensure that only cluster administrators can make such modifications. This is important in circumstances where duty separation is strictly enforced.
Furthermore, it establishes two distinct teams to whom access may be granted for administrative and observability purposes, ensuring the aforementioned separation of roles.
The policy items that are mentioned The following are the Openshift-argo items: openshiftGroup: argoGroup. Dex, an identity service that leverages OpenID Connect to drive authentication for other apps, provides Argo CD with information about the OpenShift user (such as the user’s group membership).
We utilized the ‘guestbook’ application from https://github.com/argoproj/argocd-example-apps to test the above configuration. We were able to examine the application with a user from the read-only group after it was successfully launched on OpenShift.
apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: openshift-gitops spec: destination: namespace: teamproj-dev server: https://kubernetes.default.svc project: manual source: path: guestbook repoURL: https://github.com/argoproj/argocd-example-apps targetRevision: HEAD syncPolicy: syncOptions: - Validate=false
So far, only applications, repositories, and clusters can be project scoped; however, it appears that there is a desire for scoping additional sorts of resources, such as logs, as demonstrated in
While most people would start with individual manual project creation, it is advised that teams be onboarded to GitOps using an automation approach that allows them to deploy to numerous environments in a cluster. This will allow for resource reuse and team autonomy, allowing developers to create promotion processes that are tailored to their development habits.
We used jinja templates and Ansible with a bunch of variables that are parsed in per-team to automate the above. When a new team is introduced to the platform, a procedure runs to automate the generation of the things listed above, allowing the automation to scale.