Getting started with Argo CD on OpenShift 4 is an excellent architectural move. Red Hat wraps upstream Argo CD into a fully supported platform product called Red Hat OpenShift GitOps.

By using the official GitOps operator instead of installing upstream community Argo CD via Helm, you get native integration with the OpenShift Web Console, automated Single Sign-On (SSO) using your existing cluster identity providers, and pre-configured multi-tenant security structures.

Here is the strategic roadmap and implementation guide to get your first application running.

1. Platform Installation

To maintain support and stability, you install OpenShift GitOps globally via the OperatorHub.

1. Log into your OpenShift Web Console with cluster-admin privileges.
2. Navigate to Operators ➔ OperatorHub and search for Red Hat OpenShift GitOps.
3. Click Install. Accept the default channel and allow it to install globally.

What happens in the background?

The operator automatically spins up a default, cluster-wide Argo CD instance named openshift-gitops inside the openshift-gitops namespace. It configures a public OpenShift Route so you can access the Argo CD dashboard immediately.

2. Accessing the Argo CD Dashboard

Red Hat integrates OpenShift’s native OAuth layer directly into the GitOps operator.

1. In your OpenShift Web Console, click the Application Launcher icon (the grid square in the top-right top navigation bar).
2. Click Cluster GitOps.
3. You will be redirected to the Argo CD login page. Click Log in via OpenShift and enter your standard OpenShift developer or admin credentials.

3. Configuring Multi-Tenant Permissions (The “Control Plane” Step)

By default, the central openshift-gitops instance has permissions to manage applications across the cluster, but security best practices require you to explicitly tell Argo CD which namespaces it is allowed to manage.

If your developer team works in a namespace named finance-frontend-prod, you must target it with an AppProject boundary and configure OpenShift role bindings.

Step A: Label the Target Namespace

The GitOps operator monitors namespace labels to establish underlying webhook tracking:

oc label namespace finance-frontend-prod argocd.argoproj.io/managed-by=openshift-gitops

Step B: Apply a Safe AppProject Constraint

Apply this file to your cluster to ensure that developers using this Argo CD group can only deploy specific safe resources into their designated namespace, preventing lateral privilege escalation:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: finance-project
  namespace: openshift-gitops
spec:
  description: "Secure boundary for Finance front-end microservices"
  # Permits deployments ONLY to this target namespace
  destinations:
    - namespace: finance-frontend-prod
      server: https://kubernetes.default.svc
  # Whitelists safe cluster resources; bans cluster-wide resources like ClusterRoles
  clusterResourceWhitelist:
    - group: '*'
      kind: '*'
  sourceRepos:
    - https://github.com/your-enterprise/finance-gitops-infra.git

4. Deploying Your First App Declaratively

Now that your project boundaries are established, you deploy your application using the GitOps Pull Model. Instead of using the UI, you declare an Application manifest. This tells Argo CD to watch your Git repository path and keep the cluster synchronized with its contents.

Create and apply the following Application manifest:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: banking-web-ui
  namespace: openshift-gitops
spec:
  project: finance-project # Binds the app to your secure project rules
  source:
    repoURL: https://github.com/your-enterprise/finance-gitops-infra.git
    targetRevision: HEAD     # Tracks the main branch
    path: deployments/prod   # The folder containing your Deployment/Service/Route YAMLs
  destination:
    server: https://kubernetes.default.svc
    namespace: finance-frontend-prod
  syncPolicy:
    automated:
      prune: true     # Automatically deletes resources in OCP if removed from Git
      selfHeal: true  # Overwrites manual cluster overrides to prevent configuration drift
    syncOptions:
      - CreateNamespace=false # Ensures it relies on pre-configured enterprise namespaces

5. Day-2 Operational Best Practices

Once you have your first app synced, implement these architecture rules immediately to ensure production-grade stability:

• Isolate Your Repositories: Never put your application source code (Java/Node.js) in the same Git repository as your GitOps deployment manifests. Keep your deployment YAMLs or Helm charts in a dedicated infra-gitops repository. This prevents infinite CI/CD build loops where a deployment update triggers a code rebuild.
• Avoid the cluster-admin Trap: While the default openshift-gitops instance has broad privileges, as you scale out to multiple development teams, create isolated Argo CD instances per tenant team using the operator’s ArgoCD Custom Resource. This ensures team A cannot view or alter team B’s deployment structures.
• Monitor Sync Performance: Keep an eye on your Redis cache settings within the Argo CD instance. As your GitOps repository approaches hundreds of managed resources, increase the Redis memory limits to prevent reconciliation latencies and webhook drops.