Secret key can not be omitted #1936
Comments
|
The API server is supposed to generate this. During new installations, we will sometimes see application-controller crash because it started before the api-server had a chance to generate it. Which service are your logs coming from? |
|
The log came from the application controller. |
|
Uh, the api server was not running because of PSP. I'll try it and update you again. |
|
I confirmed it is created automatically if the api server is running. |
|
Issue: The What we tried: We took the value of Output: We were getting error as unauthorized and we had no idea why. Ultimate Solution: Uninstalled and reinstalled argo from scratch and then it generated the So the |
In my situation I started having CrashLoopBackoff on argocd-dex-server in the logs I have "server.secretkey is missing" after deleting argocd namespace and creating it from scratch. I just now deleted already 3 times and recreated and still same problem. Any advice? |
|
I solved the problem with node scale out due to the problem caused by the API server not being executed. |
|
Seeing this issue after doing: Then CrashLoopBackOff on argocd-dex-server |
|
@emirot can you confirm that the API server is successfully coming up? |
|
@crenshaw-dev sorry about the noise, I figured it out, it's not related, it is due to Open Policy Agent |
|
@emirot i have the exact same issue how did you resolve yours? |
|
@brianpooe In my case I had to do add to add |
|
I have the same issue when I install argocd with Core Install. @dtaniwaki Can we reopen this issue? |
|
i do have same issue after my redis pods restarted. My argo redis do not have PVC, so this might be related. |
|
#10831 might be related I had this WorkaroundManually specifying |
|
For anyone coming here for similar issue where
|
|
I fixed it by simply restarting the server. |
|
Reopening because I think this is almost definitely a persistent problem with core install. |
|
Could we split |
|
Hello, I face a related issue on ArgoCD 2.9 managed with Helm Charts. Argo goes out of sync because of required secrets config. If I sync I loose access right away and need to re add manually secrets in Azure.
Am I the only one to encounter this issue ? Do you think it would be possible to fix this without having to ignore argocd-secret sync in argo-cm ? |
|
I'm also having this same issue with self managed argo. This virtually makes the api/ui not usable, it makes me think that it should fail the health check so that it can be restarted automatically with the new secret. |
|
I ran into the same issue as #1936 (comment) It's also simple to reproduce together with the ArgoCD Helm chart and ArgoCD managing itself. Add a github.webhook.secret: Sync it using ArgoCD. Successfully setup. Now your secret will look like this or similar: Now remove the github.webhook.secret by removing the I agree with @pgpx that the webhook secrets should be moved into their own Kubernetes Secret. This will not only solve the issue that many people in here are facing, but also make workarounds like the one currently built and proposed by @MrFreezeex in #16262 obsolete. |
Note that my PR is not fully related to your current issue my use case was more about using https://external-secrets.io/latest/ to supply webhook secrets because that's what we use in our env but that's pretty nice if it solves other similar-ish issues as well! I also believe that having what you are proposing (a separate secret) and my PR are fully compatible and should allow even better flexibility combined :D. |
How I got into this topic is also by the need to provide the secret via external-secrets. If the webhook secret would be stored in a separate secret, then we could simply provision that via external-secrets and there's no more need to reference it via the special |
|
This is also causing an issue for us when argocd-secret is itself managed by argocd, and (as mentioned above) it's compounded by the fact that the argocd-server healthcheck will still succeed even when this error is occurring and making the interface unusable. |
|
I got this problem after using In case, you are in the same situation, the workaround is to:
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: argocd-secret
spec:
secretStoreRef:
name: vault-external-secret-store
kind: ClusterSecretStore
target:
name: argocd-secret # Secret name in Kubernetes
creationPolicy: 'Merge'
template:
data:
webhook.github.secret: "{{ .github_webhook_token }}"
metadata:
annotations:
description: "The WebHook Secret that permits to authenticate the GitHub Webhook"
# Mapping to local secret from remote secret
data:
# https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/#2-configure-argo-cd-with-the-webhook-secret-optional
- secretKey: github_webhook_token # Prop Name in the secret
remoteRef:
key: argocd # Name of the remote secret
property: github-webhook-token # Prop Name in the remote secret
|
Describe the bug
Although the comment in
secret.yamlindicatesserver.secretkeycan be auto-generated if it's missing.argo-cd/docs/operator-manual/argocd-secret.yaml
Line 19 in d3c850b
However, the code doesn't allow empty
server.secretkey.argo-cd/util/settings/settings.go
Line 499 in d3c850b
Which is the expected behavior?
To Reproduce
Just after installing ArgoCD and set
admin.password(although this is not mentioned in the docs).Expected behavior
Asking the expected behavior.
Screenshots
N/A
Version
Logs
Have you thought about contributing a fix yourself?
I'm not sure which is the expected behavior.
The text was updated successfully, but these errors were encountered: