Webhooks secret not configurable

[paolocarta]

I had a look at the reference docs and I did not find a way to configure the git webhooks secret in the ArgoCD custom resource.

I think it would be great being able to do that.

[jomkz]

Hi @paolocarta, thank you for your feedback and interest in the operator.

To be clear, you are referring to the webhook secrets in the argocd-secret Secret?

  webhook.github.secret: shhhh! it's a github secret
  # gitlab webhook secret
  webhook.gitlab.secret: shhhh! it's a gitlab secret
  # bitbucket webhook secret
  webhook.bitbucket.uuid: your-bitbucket-uuid
  # bitbucket server webhook secret
  webhook.bitbucketserver.secret: shhhh! it's a bitbucket server secret
  # gogs server webhook secret
  webhook.gogs.secret: shhhh! it's a gogs server secret

[paolocarta]

Hi @jmckind thanks for your reply.

Yes I was trying to configure this secret through the operator. I did not understand whether is possibile or not using the operator's custom resource.

Did I miss anything perhaps?

[jomkz]

One thing that you could do is to just create the argocd-secret Secret before or at the same time as the ArgoCD resource with the webhook secrets that you want to use and it should work. The operator is not managing those properties currently, so you should be able to modify them as needed and the operator should not get in the way.

The operator will create argocd-secret automatically, so you should be able to use the Argo CD docs for managing the webhooks Secrets without any issues.

https://argoproj.github.io/argo-cd/operator-manual/webhook/#2-configure-argo-cd-with-the-webhook-secret-optional

[paolocarta]

Cool thanks, for the moment it's ok.

Is there any plan to support it in the future with the ArgoCD custom resource? Otherwise we might have a mix of things managed both manually and with the operator.

[jomkz]

@paolocarta Do you have ideas for how the operator could help you more in this scenario?

I do not want to enable setting those secrets directly in the CR, as that is what the argocd-secret Secret is used for and I am having trouble with what more the operator could do to help here.

[paolocarta]

@paolocarta Do you have ideas for how the operator could help you more in this scenario?

I do not want to enable setting those secrets directly in the CR, as that is what the argocd-secret Secret is used for and I am having trouble with what more the operator could do to help here.

I think it would allow to have everything in one place. The operator then would manage all necessary configurations automatically.

For instance, let's assume a secret needs to be added after the ArgoCD setup, it would require probably to get the existing secret, patch it manually and apply it. This would also apply while updating the secret I guess.

I was wondering whether we could reference a secret in the operator's CR, and then use it to patch automatically the argocd-secret with its content. Alternatively, the operator could generate a webhook secret if enabled, maybe using a flag in the CR, for instance spec.server.webhooks.secrets.generate: true.

[jomkz]

I thought that the webhook secret came from the other side like GitHub or Gitlab, etc and was not something that could be generated by the operator? Perhaps my understanding is flawed here.

[paolocarta]

I thought that the webhook secret came from the other side like GitHub or Gitlab, etc and was not something that could be generated by the operator? Perhaps my understanding is flawed here.

As far as I can see from the GitHub UI you can specify the secret while manually creating the webhook. I am not sure while using the GitHub APIs though.

[jomkz]

Ahh OK... So you can provide the value, I think I see now what you mean.

Have the operator use the API to create the webhook and secret at GitHub or GitLab, etc.? That is certainly something that we can look at having the operator manage. I will do a little more research into the various webhooks and see if there is a way that the operator can support at least some of them.

[paolocarta]

It could be configured also manually on GitHub at the beginning, with the secret created by the operator.

The version you suggests sound really interesting though, it could be really useful in a second version!

I am thinking about contributing with a PR, but my golang knowledge is a bit limited at the moment :-D.

[jomkz]

Feel free to submit the PR if you have something and we can work through anything golang related if you have questions or anything. :)

[raelga]

We have a similar issue, but in this case, for the Oauth configuration.

A possible solution is having an argocd-operator-secrets secret deployed by the user. Managing the secrets outside the operator is quite common, as is sensible information that you don't want to have in the CRD yaml spec.

The operator can retrieve the user managed secret data and merge them into the argocd-secrets secret.

[benruland]

We are experiencing the same issues and are unable to set the Webhook secret by operator (the Webhook secret ist providex by an SealedSecret). Any plans on providing a way to declaratively extend the argocd-secret?

[csfreak]

Given that we already merge data from the -cluster and -tls and support merging changes to those secrets into argocd-secret, It seems like adding support for webhook secrets would fit in architecturally. We would just need to decide wether to force a specific secret name, and always reconcile it like we do with -cluster and -tls, or wether we follow the pattern used for the TLS CA cert/key and let the user supply a secret if needed that we watch.

I would argue that adding a -webhook secret, which we treat like -cluster and -tls seems to match better. The problem with this will be the need to handle it like we do the cluster TLS certs, in order to watch it correctly and sync changes into argocd-secret, since we won't be able to set an ownerRef on that secret to trigger the reconcile of the ArgoCD object. The current logic for this requires that the secret exist when the controller starts, which is safe for cluster certs, but not for user defined certs.

Given these constraints, I see two options.

1. We can either not watch the secret for changes, and use a user provided secret, which doesn't match the behavior of our other secrets.
2. We create a '-webhook` secret with an ownerRef pointing to the ArgoCD object that reconciles like our existing secrets, and assume that whatever automation being used to populate the secret by others is capable of maintaining the secret data without removing our ownerRef.

As Option 2 matches our existing behavior, supports the requested spec.server.webhooks.secrets.generate: true, and works with at least several secret population solutions (sealed-secrets and external-secrets) , It seems like the better option.