docs/proposals/headless-argocd.md
Support "disabling" multi-tenancy features by introducing Headless Argo CD.
There are two main group of GitOps users:
Argo CD is a perfect fit for application developers thanks to its multi-tenancy features. Instead of running a separate Argo CD instance for each team, it is possible to run on the instance and leverage features like SSO, RBAC, and Web user interface. However, this is not the case for cluster administrators. Administrators prefer to rely on Kubernetes RBAC and view SSO and Argo CD RBAC as an obstacle and security threat. SSO, RBAC, and UI/API are totally optional and can be disabled but it requires additional configuration and learning.
It is proposed to introduce officially supported Headless Argo CD that encapsulates changes required to disable multi-tenancy features and provide a seamless experience for cluster administrators (or any other user who don't need multi-tenancy).
The goals of "Headless Argo CD" are:
The end-user should be able to install required components using a single kubectl apply command without following any additional instructions.
The Headless Argo CD should provide a simple way to view and manage Argo CD applications using CLI/UI. The access control should be enforced by
Kubernetes RBAC only.
It is a common case when the Argo CD adopter wants to start small and then expand Argo CD to the whole organization. It should be easy to "upgrade" headless to full Argo CD installation.
The Headless Argo CD is not modified Argo CD. It is Argo CD distribution that missing UI/API and CLI that provides commands for Argo CD admin.
The Headless Argo CD is not intended to deprecate any of the existing operational methods.
In order to simplify installation of Argo CD without API we need to introduce headless/install.yaml in the manifests directory.
The installation manifests should include only non HA controller, repo-server, Redis components, and RBAC.
Without the API server, users won't be able to take advantage of Argo CD UI and argocd CLI so the user experience won't be complete. To fill that gap
we need to change the argocd CLI that and support talking directly to Kubernetes without requiring Argo CD API Server. The argo-cd#6361
demonstrates required changes:
--headless flag to argocd commands--headless flag is set to true then pre-run function that starts "local" Argo CD API server and points CLI to locally running instanceThe user should be able to store --headless flag in config in order to avoid specifying the flag for every command. It is proposed to use argocd login --headless to generate
"headless" config.
In addition to exposing CLI commands the PR introduces argocd admin dashboard command. The new command starts API server locally and exposes Argo CD UI locally.
In order to make this possible the static assets have been embedded into Argo CD binary.
The potential users of "headless" mode will benefit from argocd-util commands. The experience won't be smooth since they will need to switch back and forth
between argocd and argocd-util. Given that we still have not finalized how users are supposed to get argocd-util binary (https://github.com/argoproj/argo-cd/issues/5307)
it is proposed to deprecate argocd-util and merge in into argocd CLI under admin subcommand:
argocd admin app generate-spec guestbook --repo https://github.com/argoproj/argocd-example-apps
Add a list of detailed use cases this enhancement intends to take care of.
As an Argo CD administrator, I would like to manage cluster resources using Argo CD without exposing API/UI outside of the cluster.
As an Argo CD administrator, I would like to use Argo CD CLI commands and user interface to manage Argo CD applications/settings using only kubeconf file and without Argo CD API access.
The Headless CLI/UI disables built-in Argo CD authentication and relies only on Kubernetes RBAC. So if the user will be able to make the same change using Headless CLI as using kubectl.
TBD
Switching to and from Argo CD Headless does not modify any persistent data or settings. So upgrade/downgrade should be seamless by just applying the right manifest file.