Red Hat OpenShift GitOps provides Argo CD and other tooling used to implement GitOps workflows for cluster configuration and application delivery. OpenShift GitOps is a Red Hat OpenShift add-on, available as an operator in the OperatorHub. Once you've installed the OpenShift GitOps operator, you can deploy Argo CD instances using Kubernetes custom resources.
OpenShift GitOps deployment modes
OpenShift GitOps supports flexible Argo CD configurations to satisfy diverse user needs in the world of GitOps, as shown in Figure 1.
Cluster-scoped Argo CD
OpenShift GitOps provides single-click enablement of GitOps for OpenShift cluster configuration. When the OpenShift GitOps operator is installed, an Argo CD instance is set up for users out of the box. It comes with the configuration required to configure a cluster in the
openshift-gitops namespace, which acts as the GitOps control plane for cluster configuration. Typical cluster configuration activities include configuring control plane operators, setting up developer namespaces, installing Operator Lifecycle Manager (OLM) operators, and managing storage.
Application-scoped Argo CD
You can create additional Argo CD instances to satisfy the needs of software development organizations sharing the same cluster. In this article, we’ll discuss how developers can create independent Argo CD instances for one or more application delivery teams using OpenShift GitOps 1.2.
Application delivery with OpenShift GitOps
To achieve absolute isolation and multitenancy, OpenShift GitOps 1.2 supports the installation of namespace-scoped Argo CD instances for one or more application delivery teams in an organization, as shown in Figure 2.
Setting up a control plane
A GitOps control plane is a namespace where Argo CD is installed. You can express an intent to deploy and sync Kubernetes manifests from Git by creating one or more application custom resources in the GitOps control plane.
To initialize a namespace-scoped Argo CD instance, you can create an Argo CD custom resource (CR) in a new namespace designated to be a GitOps control plane, as shown in the following example. This creates a minimalistic Argo CD instance with privileges to manage the contents of the namespace:
name: argocd #name of the Argo CD instance
namespace: foo #namespace where you want to deploy argocd instance
enabled: true #creates an openshift route to access Argo CD UI
Deploying an application from Git
The following code example shows how you would deploy an application from Git (also see Figure 3):
name: sample-app #app CR name
namespace: foo #argocd instance namespace
namespace: foo #namespace where app is deployed
Adding projects to the control plane
Create a namespace,
bar, and try deploying an application in this namespace, which is managed by the Argo CD instance deployed in the namespace
First, create the namespace
bar as follows:
Then, create an application custom resource in the namespace
namespace: foo #namespace where Argo CD instance is installed
namespace: bar #target namespace where app is deployed
Authorizing the GitOps control plane
The GitOps control plane will try to deploy the application in the namespace
bar. As you can see in Figure 4, the sync fails because the GitOps control plane is not authorized to deploy managed resources in the namespace
To authorize the GitOps control plane to deploy managed workloads in a namespace, the namespace owner needs to decorate the namespace resource with a label containing the reference to the namespace where the GitOps control plane resides.
The OpenShift GitOps operator reads this expression of intent to have the namespace managed by a specific GitOps control plane and configures the appropriate Argo CD secrets and Kubernetes role-based access control (RBAC).
Label the namespace as follows:
argocd.argoproj.io/managed-by: foo #argocd instance ns
This configures the existing namespace
bar with the label recognized by the OpenShift GitOps operator.
After configuring the namespace, trigger the sync from the Argo CD UI. The application will sync successfully, as shown in Figure 5.
Figure 6 shows the developer perspective after the user workload in the namespace bar has been successfully deployed.
Argo CD configuration in Red Hat OpenShift GitOps
In OpenShift GitOps 1.1.1, a security issue was reported with Argo CD instances configured for application delivery. Handling the vulnerability required significantly curtailing the privileges of Argo CD instances in OpenShift GitOps 1.1.2. This led to upgrading issues and potentially arduous manual configuration of Argo CD instances installed in developer namespaces. These issues showed up in two scenarios:
- When configuring the Argo CD cluster secret.
- When creating a rolebinding in participating namespaces with the Argo CD application controller service account.
While the change was necessary, it became a hurdle to the frictionless operation of Argo CD instances and potentially violated the principles of declarative configuration, while also exposing users to Argo CD's underlying deployment details.
As an enhancement, we fast-tracked the development of a new feature that allows users to authorize the management of OpenShift projects seamlessly:
- A team lead sets up a GitOps control plane for the team in the namespace
- Members of the team label their own namespaces referring to the
my-teamnamespace indicating that they authorize the GitOps control plane in
my-teamto manage their namespaces.
OpenShift GitOps strives to make it easy for developer teams to manage, configure, and use Argo CD securely for application delivery on OpenShift. As this article demonstrates, application delivery teams can create multiple isolated Argo CD instances on a Red Hat OpenShift cluster. This provides users and administrators with full control over what an Argo CD instance is empowered to do. Optionally, the cluster administrator can use the Argo CD instance in the
openshift-gitops namespace to declaratively manage Argo CD instances across multiple developer namespaces.