-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix(argo-cd): remove secretName for server and applicationSet Certifi…
…cates (#2741) * Remove Certificate's secretName because expected names by server and applicationset are static Signed-off-by: Erwan Vallienne <erwan@fgtech.fr> * Apply suggestions from code review Signed-off-by: Marco Maurer (-Kilchhofer) <mkilchhofer@users.noreply.github.com> * Fix lint Signed-off-by: Erwan Vallienne <erwan@fgtech.fr> --------- Signed-off-by: Erwan Vallienne <erwan@fgtech.fr> Signed-off-by: Marco Maurer (-Kilchhofer) <mkilchhofer@users.noreply.github.com> Signed-off-by: Erwan Vallienne <135604788+erwanval@users.noreply.github.com> Co-authored-by: Marco Maurer (-Kilchhofer) <mkilchhofer@users.noreply.github.com>
- Loading branch information
1 parent
e34b45b
commit b0d4648
Showing
5 changed files
with
7 additions
and
11 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
b0d4648
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@erwanval @mkilchhofer Can you please explain this change:
This is the first time in any open-source kubernetes application chart that I cannot have a custom secret name for my ingress rule. I don't know the internals of Argo CD, but the secret name for the Ingress rule should be entirely independent from the underlying service as it is only used by the Ingress Controller itself. I have always been able to use a custom name for ALL kubernetes third-party apps I have installed on my cluster, and this is a shocking first.
Please provide more information as to why this change was warranted. Isn't there an overlap (or confusion) between the TLS cert used by the server for communication with the other Argo CD components and the TLS cert simply used to authenticate the domain by the Ingress Controller to the public web clients ?
b0d4648
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adamency This change doesn't concern the ingress TLS certificate, but the one exposed by ArgoCD pods.
According to the doc (and my tests following the issue I encountered initially):
So in summary, the secret MUST have a predefined name, otherwise it's just ignored.
But again, this is only for TLS exposed by the pods themselves, not the ingress.
You can still configure your own TLS secret for ingresses by using
server.ingress.extraTls
orapplicationSet.ingress.extraTls
values.I hope it clarify things for you
b0d4648
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@erwanval Thanks a lot for your answer.
I guessed so about this being for the TLS between pods, however as I explained, there is overlap with the
Ingress
as thissecretName
is the variable that will actually be used in the Ingress rule for the secret name in its TLS section.And I had already tried using
server.ingress.extraTls
, this creates a duplicatehost
in thetls
sectionof the
Ingressresource only with the secret name being different, instead of overwriting the secret name in the original
host`.Here is the output of a Helm dry-run with this values override file:
values-override.yaml
helm install --dry-run -f values-override.yaml [...]
So now, that makes two
host
definitions with the same hostname, but different secrets. This would confuse Cert-Manager about which certificate name to use (and wouldn't this cause issues overall anyway ?)But in the end, I still don't understand why the
secretName
variable should appear in theIngress
resource at all. Correct me if I'm wrong, but can't we simply create theSecret
resourceargocd-server-tls
in the chart and leave the Ingressspec.tls.host.secretName
variable outside of it ?The real question is why a variable supposedly only involved in intra-cluster Pods communication is used in the
Ingress
resource, which is a resource meant specificallly only for external communication ?Isn't there a bug in the chart code ? Either that, or there is something I am missing and is not explained in the excerpt you shared.