Skip to content

v2.6 to 2.7

Configure RBAC to account for new extensions resource

2.7 introduces the new Proxy Extensions feature with a new extensions RBAC resource.

When you upgrade to 2.7, RBAC policies with * in the resource field and * in the action field, it will automatically grant the extensions privilege.

The Proxy Extension feature is disabled by default, however it is recommended to check your RBAC configurations to enforce the least necessary privileges.

Example Old:

p, role:org-admin, *, *, *, allow

New:

p, role:org-admin, clusters, create, my-proj/*, allow
p, role:org-admin, projects, create, my-proj/*, allow
p, role:org-admin, applications, create, my-proj/*, allow
p, role:org-admin, repositories, create, my-proj/*, allow
p, role:org-admin, certificates, create, my-proj/*, allow
p, role:org-admin, accounts, create, my-proj/*, allow
p, role:org-admin, gpgkeys, create, my-proj/*, allow
# If you don't want to grant the new permission, don't include the following line
p, role:org-admin, extensions, invoke, my-proj/*, allow

Upgraded Helm Version

Note that bundled Helm version has been upgraded from 3.10.3 to 3.11.2.

Upgraded Kustomize Version

Note that bundled Kustomize version has been upgraded from 4.5.7 to 5.0.1.

Notifications: ^ behavior change in Sprig's semver functions

Argo CD 2.7 upgrades Sprig templating specifically within Argo CD notifications to v3. That upgrade includes an upgrade of Masterminds/semver to v3.

Masterminds/semver v3 changed the behavior of the ^ prefix in semantic version constraints. If you are using sprig template functions in your notifications templates which include references to Sprig's semver functions and use the ^ prefix, read the Masterminds/semver changelog to understand how your notifications' behavior may change.

Tini as entrypoint

The manifests are now using tini as entrypoint, instead of entrypoint.sh. Until 2.8, entrypoint.sh is retained for upgrade compatibility. This means that the deployment manifests have to be updated after upgrading to 2.7, and before upgrading to 2.8 later. In case the manifests are updated before moving to 2.8, the containers will not be able to start.

Deep Links now allow you to access other values like cluster, project, application and resource in the url and condition templates for specific categories of links. The templating syntax has also been updated to be prefixed with the type of resource you want to access for example previously if you had a resource.links config like : 

  resource.links: |
    - url: https://mycompany.splunk.com?search={{.metadata.name}}
      title: Splunk
      if: kind == "Pod" || kind == "Deployment"
This would become : 
  resource.links: |
    - url: https://mycompany.splunk.com?search={{.resource.metadata.name}}&env={{.project.metadata.label.env}}
      title: Splunk
      if: resource.kind == "Pod" || resource.kind == "Deployment"

Read the full documentation to see all possible combinations of values accessible fo each category of links.

Support of helm.sh/resource-policy annotation

Argo CD now supports the helm.sh/resource-policy annotation to control the deletion of resources. The behavior is the same as the behavior of argocd.argoproj.io/sync-options: Delete=false annotation: if the annotation is present and set to keep, the resource will not be deleted when the application is deleted.

Check your Kustomize patches for --redis changes

Starting in Argo CD 2.7, the install manifests no longer pass the Redis server name via --redis.

If your environment uses Kustomize JSON patches to modify the Redis server name, the patch might break when you upgrade to the 2.7 manifests. If it does, you can remove the patch and instead set the Redis server name via the redis.server field in the argocd-cmd-params-cm ConfigMap. That value will be passed to the necessary components via valueFrom environment variables.

argocd applicationset CLI incompatibilities for ApplicationSets with list generators

If you are running Argo CD v2.7.0-2.7.2 server-side, then CLI versions outside that range will incorrectly handle list generators. That is because the gRPC interface for those versions used the elements field number for the new elementsYaml field.

If you are running the Argo CD CLI versions v2.7.0-2.7.2 with a server-side version of v2.7.3 or later, then the CLI will send the contents of the elements field to the server, which will interpret it as the elementsYaml field. This will cause the ApplicationSet to fail at runtime with an error similar to this:

error unmarshling decoded ElementsYaml error converting YAML to JSON: yaml: control characters are not allowed

Be sure to use CLI version v2.7.3 or later with server-side version v2.7.3 or later.