argo-cd
argo-cd copied to clipboard
ESO - Support display for ClusterExternalSecret
Summary
Currently, external secret objects are correctly displayed with their related secret as in the example below
but cluster external secret that create & manage multiple external secret in different namespace are not
Motivation
In order to see the complete graph, ClusterExternalSecret should be linked to the ExternalSecrets they manage.
Proposal
The same way ExternalSecret shows the Secret it manages, ClusterExternalSecret should show all managed ExternalSecret (in each targetted namespaces) - and then the Secrets related to the ExternalSecret objects.
Important: ExternalSecret objects will have all the same name, so the namespace name must be reflected into the UI as well in order to easily distinct which one is which.
The Cluster External Secret is a component added recently (~2 months ago?) on the external secret operator, so i guess it's not yet supported by Argo.
Any idea when this could be added ? We plan to replace our secret management by ESO in the coming days, would be great to easily see it on the UI.
Can someone look at this ?
CES using namespace selector with matching expression + In operator + multiple values will be fixed (https://github.com/external-secrets/external-secrets/issues/1155) and released within a week. Please update to the newest version in order to test & dev the support of CES.
up
@nicolas-vivot I believe Argo CD constructs the tree based on metadata.ownerReferences
. Is that populated in the ClustExternalSecret resource?
@crenshaw-dev
If ArgoCD constructs the tree based on metadata.ownerReferences
, then why it can build a tree for an application including a configuration map even when such object has no metadata.ownerReferences
?
Taking the example of external secrets, there is no metadata.ownerReferences` information on the secret object owned by an external secret, still ArgoCD is able to build the tree.
From what i see, currently only the external secrets has metadata.ownerReferences
specified, referring to the cluster external secrets owning it.
I too am interested in this, I can offer some more details for @crenshaw-dev .
A ClusterExternalSecret (CES) is a resource whose primary use is creating ExternalSecrets (ES) in many cluster namespace.
Now metadata.ownerReferences
are only allowed in the same namespace, as these are all namespace-scoped objects, so that won't help us.
I thought I could work around this by adding an appropriate label, like app.kubernetes.io/instance: CES-owning-app
to all the automatically generates ES, like https://argo-cd.readthedocs.io/en/stable/user-guide/resource_tracking/ suggests.
This was not supported by ESO, so I opened https://github.com/external-secrets/external-secrets/issues/2400 to add support for setting labels and annotations in the generated ESs. The nice guys at ESO added it and released the other day in 0.9.0.
I was super sad to discover that adding app.kubernetes.io/instance: CES-owning-app
to the generated ESs made no difference in the argo UI, unlike what the doc above claims.
I don't care (much) about the parent-child relation, but I very much want to see these resources in the UI and I don't want to do it by cheating with project-level namespace orphan tracking.
Is there some other label/annotation I can add to the generated resources? Maybe editing the Application definition? Thanks for your time.