ArgoCD

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 WWUKube 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. However, please note that the recommended usage patterns and guidelines for our tenants may still be under development.

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

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:

• dev-ms1: https://argocd.ms1.dev.k8s.wwu.de
• dev-ms2: https://argocd.ms2.dev.k8s.wwu.de
• staging-ms1: https://argocd.ms1.staging.k8s.wwu.de
• staging-ms2: https://argocd.ms2.staging.k8s.wwu.de
• prod-ms1: https://argocd.ms1.k8s.wwu.de
• prod-ms2: https://argocd.ms2.k8s.wwu.de

Add ArgoCD Applications to your WWUKube Project

Deployment of resources using ArgoCD requires inclusion of a sources section within the WWUKube Project Custom Resource Definition (CRD). The sources section features two essential entries: repoURL and targetRevision. This will result in the creation of an ApplicationSet, which possesses the capability to generate Applications. Here is an example of how the Project CRD may appear with the included source section:

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
      source:
        repoURL: <repo-url>
        targetRevision: <branch>

In order to create these Applications, it is necessary to create YAML files and store them in the designated Git repository, under the directory structure of .argocd/<environment>-<region>/<namespace>. Each unique YAML file corresponds to a distinct Application generation. Presented below is an example YAML file: .argocd/<environment>-<region>/<namespace>/<application-name>.yaml

directory: resources/path

ArgoCD will autonomously produce an Application named tenant-<project-name>-<application-name>, responsible for deploying any resources referenced in the resources/path/ directory onto the predesignated cluster and Namespace. The resource definitions have to be contained within a single YAML file named resources.yaml, which serves as a manifest containing all required objects. Currently, our ArgoCD does not support Helm chart generation; therefore, any usage of Helm, Kustomize, or other templating tools should be executed locally on your workstation. Once generated, the resulting resources should then be committed to the designated resources/path/resources.yaml file within your git repository.

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

Two alternative methods are available for deploying secrets utilizing ArgoCD, both of which involve the integration with HashiCorp Vault. Vault secures and protects sensitive data with features like secret management, encryption services, and identity-based access control – ensuring safety and ease of use for authorized users. You can find the Vault instance operating at https://vault.uni-munster.de/. Additional details concerning Vault can be obtained through their official website https://www.vaultproject.io/.

Access to the vault is exclusively granted through admin groups, with no provision for individual admin listings.

To authenticate with Vault using the Command Line Interface (CLI), execute the following command: (assuming Vault is installed)

vault login -method=oidc

ArgoCD Vault Plugin (AVP)

We utilizes the ArgoCD Vault Plugin (AVP) to handle sensitive data and secrets when deploying applications. Instead of storing secrets in Git repositories, we keep them safe in the Vault. Upon deployment, ArgoCD interacts with the Vault using the AVP to fetch the secrets and replace designated placeholders in configuration files accordingly.

We enable independent secret storage through unique key-value stores per project. Project-specific key-value stores are created under kv-tenant-<project-name>.

Each resource within a project gains exclusive read access to the following paths within the tenant-specific key-value store:

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

While deploying resources, ArgoCD obtains temporary reading privileges for all listed paths above. Moreover, members belonging to the projects administrator groups possess both reading and writing authorizations concerning these routes.

For more information regarding the usage and capabilities of the AVP, please refer to its official documentation at https://argocd-vault-plugin.readthedocs.io/en/stable/howitworks/.

SOPS

By utilizing SOPS, it is possible to encrypt both resources and their associated secrets, enabling secure storage of these sensitive details within a Git repository.

In order to activate support for SOPS integration within ArgoCD, please execute the following actions:

• Set the value of sops: true in your <application>.yaml configuration file.
• Rename your resources file from resources.yaml to resources.enc.yaml.

We offer a Vault transit engine labeled tr-tenant-<project-name> along with a designated key titled <environment>-<region>-<namespace>. To permit ArgoCD decryption of the resources file, include the key in the SOPS config like this:

creation_rules:
  - path_regex: resources/path/resources.enc.yaml$
    hc_vault_transit_uri: "https://vault.uni-muenster.de/v1/tr-tenant-<project-name>/keys/<environment>-<region>-<namespace>"

Users of the admin groups may use the transit engine for encryption & decryption, but ArgoCD will be restricted to decryption usage alone, upholding assigned responsibilities and functionalities.

For further details concerning SOPS, please consult its official Github repository located at https://github.com/getsops/sops.