Argo CD 3.0: Navigating the Next Frontier of GitOps Deployment

In the rapidly evolving landscape of Kubernetes deployments, Argo CD 3.0 emerges as a pivotal milestone that promises to redefine how organizations approach continuous delivery. This version represents a carefully orchestrated evolution of the platform, balancing innovation with practical considerations for enterprise deployments.

Version Support Strategy

Starting with 3.0, Argo CD will:

• Stop releasing new 2.x minor versions

• Continue cutting patch releases for the two most recent minor versions (2.14 until 3.2 is released, and 2.13 until 3.1 is released)

The versioning strategy reflects a mature approach to software maintenance, ensuring stability while pushing the boundaries of continuous delivery technologies.

The v3 RC is planned for March 17, 2025 and v3 GA for May 6, 2025.

Critical Breaking Changes and Deprecations

1. Fine-Grained RBAC Transformation

The role-based access control (RBAC) mechanism in Argo CD has undergone a significant transformation, addressing long-standing challenges in permission management. Previously, the system operated with broad, catch-all permissions that often introduced potential security risks.

Before v3:

• Update or delete actions on an application automatically applied to sub-resources

• Broad permissions were the default, potentially exposing systems to unintended modifications

In v3:

• Update and delete actions now only apply to the application itself

• Explicit policies must be defined for sub-resource permissions

• Administrators can create highly specific access rules with fine-grained control

The new permission model introduces a more complex but powerful approach to access management. Example scenarios:

Granular Resource-Level Permissions To grant a user permission to delete only Pods within a specific application, you can now use a precisely crafted policy:

# Allows deleting Pods in the 'prod-app' Application
p, example-user, applications, delete/*/Pod/*/*, default/prod-app, allow

Nuanced Access Control The system now supports intricate permission combinations. For instance, you can:

• Allow updates to an application while denying updates to its sub-resources

• Explicitly deny application deletion while permitting specific resource deletions

# Explicitly deny application deletion
p, example-user, applications, delete, default/prod-app, deny

# Allow deleting Pods within the application
p, example-user, applications, delete/*/Pod/*/*, default/prod-app, allow

Glob Pattern Considerations Argo CD’s RBAC uses a unique glob pattern evaluation that requires careful configuration. The matching can be complex due to how slashes are processed. Best practices include:

• Always include all resource parts in the pattern

• Use four slashes for most precise matching

• Be aware that resource kinds and namespaces can interact in unexpected ways

Migration Strategy Organizations can preserve the previous broad permission model by setting server.rbac.disableApplicationFineGrainedRBACInheritance to false in the Argo CD ConfigMap. However, this is recommended only as a temporary measure during migration.

Example Migration Path

# Legacy Approach (No Longer Default)
- p, some-user, applications, *, *, allow  # Gave broad permissions

# New Approach
- p, some-user, applications, *, *, allow  # Requires explicit sub-resource permissions
- p, some-user, applications, update/*/Deployment/*/*, specific-app, allow

2. Logs RBAC Enforcement

The approach to logging access has been dramatically refined, treating logs as a first-class security resource. This change represents a more nuanced and secure method of managing application visibility and access.

Changes:

• Logs are now a first-class RBAC resource

• Automatic logs access for application users has been removed

• Explicit logs access must now be granted

Configuration:

• Remove server.rbac.log.enforce.enable from argocd-cm ConfigMap

• Manually grant logs access at project or global scope

3. Metrics Consolidation

Metric management has been streamlined to provide a more focused and efficient monitoring experience. The removal of certain legacy metrics demonstrates Argo CD’s commitment to maintaining a clean and modern observability approach.

Removed Metrics:

• argocd_app_sync_status

• argocd_app_health_status

• argocd_app_created_time

Migration:

• These metrics’ information is now available as labels on argocd_app_info

• Update monitoring dashboards and alerts accordingly

4. Dex SSO Authentication Changes

Authentication mechanisms have been refined to provide more stable and predictable user identification. This change addresses the inherent challenges of using internally generated claims for authentication and authorization.

Before:

• Used sub claim for RBAC subject

• Subject based on Dex internal implementation

In v3:

• Now uses federated_claims.user_id claim

• Requests federated:id scope from Dex

# Old Policy (Incorrect)
- g, ChdleGFtcGxlQGFyZ29wcm9qLmlvEgJkZXhfY29ubl9pZA, role:example

# New Policy
- g, example@argoproj.io, role:example

5. Repository Configuration

The approach to repository management has been simplified and standardized, pushing organizations towards more declarative and Kubernetes-native configuration methods.

Deprecation:

• Removed support for repository configuration in argocd-cm ConfigMap

• All repositories must now be managed as Kubernetes Secrets

Verification:

kubectl get cm argocd-cm -o=jsonpath="[{.data.repositories}, {.data['repository.credentials']}, {.data['helm.repositories']}]"

6. ApplicationSet Nested Selectors

The ApplicationSet configuration has been simplified to provide more predictable and consistent behavior across different deployment scenarios.

Change:

• applyNestedSelectors field is now ignored

• Nested selectors are always applied

• Remove explicit selectors in existing ApplicationSets

7. Cluster Configuration

Cluster management has been refined to provide more explicit and controlled interaction with in-cluster resources, reducing ambiguity in deployment configurations.

When cluster.inClusterEnabled is set to "false":

• Existing in-cluster Applications will be in an Unknown state

• Cannot create new in-cluster Applications

• Deleting Applications will not delete previously managed resources

8. Health Status Tracking

Performance optimization has been a key focus, with changes designed to reduce unnecessary load on the application controller while maintaining comprehensive resource tracking.

Before:

• Health status persisted under /status in Application CR

• Caused load on application controller

In v3:

• Health status stored externally

• Can revert by setting controller.resource.health.persist to true

9. Plugin Environment Variables

Plugin management has been enhanced to provide more flexibility and consistency in configuration handling.

New Behavior:

• Empty environment variables are now passed to config management plugins

spec:
  source:
    plugin:
      name: example-plugin
      env:
        - name: VERSION
          value: "1.2.3"
        - name: DATA  # Now passed as an empty string
          value: ""

Conclusion

Argo CD 3.0 represents a significant step in refining GitOps practices. While the changes require careful migration, they ultimately provide more granular control, improved security, and cleaner configuration management. For detailed changes and explanations checkout the official Agro CD documentation here.

PS:- I still do kubectl edit on production. ;)