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
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:
p, example-user, applications, delete/*/Pod/*/*, default/prod-app, allow
Nuanced Access Control The system now supports intricate permission combinations. For instance, you can:
p, example-user, applications, delete, default/prod-app, deny
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
- p, some-user, applications, *, *, allow
- p, some-user, applications, *, *, allow
- 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:
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:
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:
In v3:
- g, ChdleGFtcGxlQGFyZ29wcm9qLmlvEgJkZXhfY29ubl9pZA, role:example
- 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:
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:
In v3:
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
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. ;)
