ArgoCD

Using ArgoCD as a tenant

Introduction

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes. It allows you to define your application’s desired state in code and automatically synchronizes that state with the cluster. This ensures that your applications are always running in the configuration defined by your code, reducing errors and increasing reliability.

We have implemented ArgoCD in our Kube clusters and are now making it available for use by our tenants. The current implementation of ArgoCD in our clusters has been thoroughly tested and is considered stable for operation.

For more detailed information and instructions on using ArgoCD, please refer to the official documentation at https://argo-cd.readthedocs.io/en/stable.

Since we provide group based access to our services like ArgoCD and Vault, they can only be used with an admin group in the project!

Accessing ArgoCD Instances

We maintain separate ArgoCD instances for different environments and locations. Each instance has its own unique URL based on the target environment and location. Here is a list of all available ArgoCD instances along with their respective URLs:

Concept

Our ArgoCD setup for tenants uses Apps in any Namespace together with Impersonation. This means:

  • Tenants create their Application resources directly inside their own namespace via kubectl (e.g. as part of their existing deployment workflow).
  • For each tenant, we provide a pre-created AppProject named tenant-<namespace> that restricts where Applications may deploy to and which Git repositories may be used.
  • Resources are deployed using a dedicated ServiceAccount named argocd inside the tenant namespace. This Service Account has the same permissions in the namespace as your admin accounts, meaning ArgoCD can only do what you yourself are allowed to do.
  • Other Kubernetes resources like AppProject or the ArgoCD RBAC ConfigMap are still managed by us; you only manage your own Application resources.

Enabling ArgoCD for your Kube Project

To enable ArgoCD for a resource within your Kube Project Custom Resource Definition (CRD), add the following fields:

apiVersion: k8s.wwu.io/v1alpha1
kind: Project
metadata:
  name: <project-name>
spec:
  name: <project-name>
  ...
  resources:
    - environment: <environment>
      regions:
        - <region>
      namespace: <namespace>
      dnsEntries: []
      admins: []
      adminGroups:
        - <admin-group>
      limits:
        nvidia.com/gpu: 0
        cpu: 2
        memory: 2
        ephemeralStorage: 2
        persistentStorage: []
      requests:
        cpu: 2
      argocd:
        enabled: true
        sourceRepos:
          - <repo-url>
      esoServiceAccount: true

This will create:

  • An AppProject named tenant-<namespace> that is restricted to your namespace and to the listed sourceRepos.
  • A ServiceAccount named argocd in your namespace, which is used by ArgoCD for impersonation during sync. It has the same permissions in the namespace as your admin group.
  • The required RBAC so that members of your admin group(s) can manage Application resources both via the ArgoCD UI/CLI and via kubectl in their namespace.

The esoServiceAccount: true field is required if you want to use Secret Management with the External Secrets Operator (see below).

Creating Applications

Once enabled, you can create your ArgoCD Application resources directly inside your namespace. A minimal example looks like this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: <namespace>
spec:
  project: tenant-<namespace>
  source:
    repoURL: <repo-url>
    targetRevision: main
    path: path/to/manifests
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Important constraints (enforced by the AppProject and by Gatekeeper):

  • spec.project must be tenant-<namespace>.
  • spec.destination.namespace must be your own namespace.
  • spec.source.repoURL (or sources[].repoURL) must be one of the repositories listed in argocd.sourceRepos of your Project CRD.
  • spec.source.plugin and spec.sources.plugin are not allowed.

Once applied with kubectl, the Application will show up in the ArgoCD UI under the tenant-<namespace> project, and ArgoCD will take over reconciliation from there.

You can use any templating tool supported by ArgoCD (Helm, Kustomize, plain manifests, …) — there is no longer a restriction to a single resources.yaml file.

Gitlab Access

In order for ArgoCD to access the specified GitLab repository, it must be publicly or internally available. If the repository is private, you will need to grant reading permissions to the user @sddcdeployuser with a role of Reporter.

Secret Management

The recommended way to manage secrets is the External Secrets Operator (ESO) in combination with our HashiCorp Vault instance.

When you set esoServiceAccount: true in your Project CRD, we automatically create:

  • A ServiceAccount and corresponding token Secret in your namespace.
  • A SecretStore named vault-backend in your namespace, pre-configured to authenticate against Vault using the per-cluster Kubernetes auth mount.

You can then create ExternalSecret resources in your namespace that reference the vault-backend SecretStore. For details on how to author ExternalSecret manifests, please refer to the dedicated External Secrets Operator documentation.

Vault Structure

We provide an independent Key-Value store per project at the Vault path kv-tenant-<project-name>.

The Service Account in your namespace has read access to the following paths within your project-specific Key-Value store:

  • /<environment>-<region>/<namespace>/*
  • /<environment>/<namespace>/*
  • /<environment>-<region>/common/*
  • /<environment>/common/*
  • /common/*

Members of your admin group(s) have both read and write permissions on these paths and can manage the secrets through the Vault UI or CLI.

Access to Vault is exclusively granted through admin groups; there is no provision for individual admin listings.

To authenticate with Vault using the CLI (assuming Vault is installed):

vault login -method=oidc

You can find the Vault instance at https://vault.uni-muenster.de/. Additional details about Vault are available at https://www.vaultproject.io/.

ArgoCD Vault Plugin (AVP) [DEPRECATED]

Deprecated: The ArgoCD Vault Plugin (AVP) integration has been replaced by the External Secrets Operator. New projects should not use AVP. Existing projects should plan a migration to ESO.

The AVP integration is no longer offered for new tenants. The path structure within Vault is identical to the one described above for ESO, so migration is mostly a matter of replacing <placeholder> style references with proper ExternalSecret resources.

SOPS [DEPRECATED]

Deprecated: SOPS-based secret encryption is no longer recommended and is being phased out. New projects should use the External Secrets Operator instead.

Migration from the Old ApplicationSet-Based Setup

The previous tenant setup based on centrally managed ApplicationSet resources and .argocd/... directories is deprecated and will be removed in the future. Existing tenants can continue using it during the transition period, but no new tenants will be onboarded onto the old model.

Tenants should migrate to the new “Apps in any Namespace” pattern based on tenant-managed Application resources and the External Secrets Operator (ESO).

A detailed migration guide, including an end-to-end example, is available in the accompanying blog post: Reworking ArgoCD for Tenants: Apps in Namespaces, Impersonation and ESO.