Respect the selected Argo CD context when provisioning credentials

[AJaccP]

Overview

The argocd CLI lets ARGOCD_SERVER and ARGOCD_AUTH_TOKEN override the server and token of whichever context is selected. The plugin provisioned both for every command, so switching contexts with argocd context or passing --argocd-context had no effect: every command went to the server stored in the 1Password item, and --server <other> sent the stored token to whichever server the user named.

When the item has an Address, the provisioner now resolves the server argocd is about to use, in argocd's own order (--server, then ARGOCD_SERVER, then the context named by --argocd-context, then current-context from the config file), and only provisions when that server matches the Address. Otherwise it provisions nothing and argocd uses its own config. If the target cannot be determined, the token is provisioned as before. login and relogin no longer require authentication, since both connect to a server the plugin cannot see and obtain their own token.

Type of change

• Created a new plugin
• Improved an existing plugin
• Fixed a bug in an existing plugin
• Improved contributor utilities or experience

Related Issue(s)

• Resolves: Plugin should respect context - kubectl context and/or argocd-context #526

How To Test

Unit tests, including regression tests for the reported behaviour:

go test ./plugins/argocd/ -v

TestAddressAwareProvisioner covers the current context matching and not matching the item's Address, --argocd-context and --server pointing at the item's server and at another one, an exported ARGOCD_SERVER, the legacy ~/.argocd config location, and address normalisation. TestArgocdCLINeedsAuth checks that login and relogin skip authentication.

End to end with the CLI, using a 1Password item whose Address is your production server and an argocd config with a second, local context:

argocd context <local-context>
argocd account get-user-info

Before the change this returned the production user regardless of the selected context. It should now return the local one. argocd account get-user-info --argocd-context <production-context> should still authenticate with the 1Password token.

Changelog

The Argo CD plugin now respects the selected context: credentials from 1Password are only provided when argocd is targeting the server stored in the item's Address, so switching contexts and --argocd-context, --server work as they do without the plugin.