Argo CD

Argo CD supports three primary methods for integrating Google Workspace users via Dex:

1. OpenID Connect (OIDC) using Dex: The recommended method if you do not require Google Group membership information for RBAC.
2. SAML App Auth using Dex: Uses SAML to authenticate. Warning: Dex documentation recommends avoiding this method as SAML is considered unsafe and the module may be deprecated.
3. OpenID Connect plus Google Groups using Dex: The recommended method if you need to use Google Group membership in your RBAC configuration (e.g., assigning roles to sysadmins@yourcompany.com).

After setting up any of these, you must configure permissions in the argocd-rbac-cm ConfigMap.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.default: role:readonly

The GitOps Engine is a library that implements core GitOps capabilities. It provides the following features:

• Kubernetes resource cache: Efficiently manages and retrieves Kubernetes resources.
• Resources reconciliation: Handles the logic for bringing the cluster state in line with the desired state.
• Sync Planning: Generates plans for synchronizing resources.
• Access to Git repositories: Provides mechanisms to interact with Git-based source control.
• Manifest Generation: Supports the creation of manifests from source definitions.

Argo CD is undergoing scalability benchmarking to provide empirical evidence for large-scale deployments. The goal is to move beyond general scaling documentation and provide specific, quantified guidelines.

Key objectives include:

• Creating repeatable benchmarking procedures (via a proposed argoproj-labs/argo-cd-benchmarking repository).
• Determining the baseline performance of default configurations (resource allocations and replicas).
• Quantifying how parameters like replicas, sharding, and parallelism impact performance.
• Establishing metrics and thresholds for automated scaling and performance alerting.
• Providing vendor-agnostic recommendations for different deployment topologies.

The ApplicationSet controller is a Kubernetes controller that manages the ApplicationSet CustomResourceDefinition (CRD). It is designed to automate and scale the management of Argo CD Application resources across multiple clusters and within monorepos.

Key capabilities include:

• Multi-cluster targeting: Use a single manifest to deploy to many clusters.
• Multi-app deployment: Use a single manifest to deploy multiple applications from one or more Git repositories.
• Monorepo support: Efficiently manage multiple Argo CD Application resources defined within a single Git repository.
• Multitenancy: Enables individual tenants in a cluster to deploy applications without requiring privileged cluster administrator intervention.

Starting with Argo CD v2.3, the ApplicationSet controller is bundled with the main Argo CD installation.

Argo CD follows semver-like versioning rules that dictate the complexity of an upgrade:

• Patch releases (e.g., v1.5.1 to v1.5.3): Do not introduce breaking changes. No special instructions are typically required.
• Minor releases (e.g., v1.3.0 to v1.5.2): May introduce minor changes that require workarounds. You must review the upgrade instructions for every minor version jump in the sequence (e.g., check both v1.3 to v1.4 and v1.4 to v1.5).
• Major releases: Introduce backward incompatible behavior changes. It is highly recommended to perform a backup of Argo CD settings using the disaster recovery guide before proceeding.

Go templates in ApplicationSet have specific constraints that you must follow to avoid errors:

1. Field Type Restriction: Templates can only be applied to string fields. You cannot use templating on boolean fields (e.g., useCredentials) or object fields (e.g., syncPolicy).
2. No Cross-Field Control Flow: You cannot use control keywords (like {{range}} or {{end}}) that span across multiple YAML fields. Each field is evaluated as an independent template. For example, you cannot start a {{range}} in one list item and end it in another.
3. Git Generator Restriction: When using the Git generator, signature verification is not supported for the templated project field.

The repo-server manages Git and Helm repositories. While it does not have Kubernetes privileges or store credentials, users should be aware of the following risks:

• Unauthorized Deployments: Anyone with write access to a trusted Git repository can modify manifests to deploy malicious images or delete resources.
• Tool Command Invocation: Argo CD executes helm template and kustomize build. An attacker with Git access could craft malicious charts/kustomizations to attempt out-of-tree file reads on the repo-server.
• Remote Bases and Dependencies: Kustomize and Helm can reference external repositories (remote bases/dependencies) that may not be in your Argo CD allow-list, potentially introducing un-audited resources.

When using ApplicationSet in multiple namespaces, you must ensure your AppProject resources are configured to allow the source namespaces where the ApplicationSet resides.

If an ApplicationSet is created in namespace team-one-cd, the AppProject it uses must include team-one-cd in its spec.sourceNamespaces field. If this is not configured, the generated Applications will be rejected because they are being sourced from an unauthorized namespace.

kind: AppProject
apiVersion: argoproj.io/v1alpha1
metadata:
  name: team-one-project
  namespace: argocd
spec:
  sourceNamespaces:
  - team-one-cd

The service account used for impersonation is determined at the Application level, not the individual resource level.

• If spec.destination.namespace is set: The impersonation logic uses this namespace to match against the AppProject.spec.destinationServiceAccounts list.
• If spec.destination.namespace is NOT set: The Application's own namespace (where the Application CR resides) is used to scope the service account lookup.
• Cross-namespace service accounts: If you provide a service account in the format mynamespace:my-sa, Argo CD will attempt to use system:serviceaccount:mynamespace:my-sa regardless of the application's destination namespace.