Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenSearch re-creates certificates when deployed through ArgoCD #24643

Closed
NandoTheessen opened this issue Mar 25, 2024 · 2 comments
Closed

OpenSearch re-creates certificates when deployed through ArgoCD #24643

NandoTheessen opened this issue Mar 25, 2024 · 2 comments
Assignees
Labels
opensearch solved tech-issues The user has a technical issue about an application

Comments

@NandoTheessen
Copy link

Name and Version

bitnami/opensearch:0.9.1

What architecture are you using?

None

What steps will reproduce the bug?

Deploy OpenSearch through ArgoCD with autoGenerated certificates

Are you using any custom parameters or values?

security.tls.autoGenerated: true

What is the expected behavior?

The deployment should be stable, certificates should not change

What do you see instead?

On every commit to the repository housing GitOps configuration, new certificates are generated which triggers a re-deployment of all pods.

This also happens on commits that are entirely unrelated to the configuration of OpenSearch.

Additional information

No response

@NandoTheessen NandoTheessen added the tech-issues The user has a technical issue about an application label Mar 25, 2024
@github-actions github-actions bot added the triage Triage is needed label Mar 25, 2024
@github-actions github-actions bot removed the triage Triage is needed label Apr 1, 2024
@github-actions github-actions bot assigned migruiz4 and unassigned carrodher Apr 1, 2024
@migruiz4
Copy link
Member

migruiz4 commented Apr 2, 2024

Hi @NandoTheessen,

The bitnami/opensearch chart already includes a feature to reuse existing secrets called common.secrets.lookup:

{{- $secretName := printf "%s-crt" (include "opensearch.master.fullname" .) }}
---
apiVersion: v1
kind: Secret
metadata:
name: {{ $secretName }}
namespace: {{ include "common.names.namespace" . | quote }}
labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 4 }}
app.kubernetes.io/component: master
{{- if .Values.commonAnnotations }}
annotations: {{- include "common.tplvalues.render" ( dict "value" .Values.commonAnnotations "context" $ ) | nindent 4 }}
{{- end }}
type: kubernetes.io/tls
data:
tls.crt: {{ include "common.secrets.lookup" (dict "secret" $secretName "key" "tls.crt" "defaultValue" $cert.Cert "context" $) }}
tls.key: {{ include "common.secrets.lookup" (dict "secret" $secretName "key" "tls.key" "defaultValue" $cert.Key "context" $) }}
ca.crt: {{ include "common.secrets.lookup" (dict "secret" $secretName "key" "ca.crt" "defaultValue" $ca.Cert "context" $) }}

The common.secrets.lookup is a lib function from our bitnami/common chart that relies on Helm's lookup function to reuse existing secrets when deploying.

Usage:
{{ include "common.secrets.lookup" (dict "secret" "secret-name" "key" "keyName" "defaultValue" .Values.myValue "context" $) }}
Params:
- secret - String - Required - Name of the 'Secret' resource where the password is stored.
- key - String - Required - Name of the key in the secret.
- defaultValue - String - Required - The path to the validating value in the values.yaml, e.g: "mysql.password". Will pick first parameter with a defined value.
- context - Context - Required - Parent context.
*/}}
{{- define "common.secrets.lookup" -}}
{{- $value := "" -}}
{{- $secretData := (lookup "v1" "Secret" (include "common.names.namespace" .context) .secret).data -}}
{{- if and $secretData (hasKey $secretData .key) -}}
{{- $value = index $secretData .key -}}
{{- else if .defaultValue -}}
{{- $value = .defaultValue | toString | b64enc -}}
{{- end -}}
{{- if $value -}}
{{- printf "%s" $value -}}
{{- end -}}
{{- end -}}

If the lookup function fails, it will then recreate a new value.

The issue in this case is not related to the chart itself, but to ArgoCD not supporting Helm's lookup function: argoproj/argo-cd#5202

I'm sorry but there is not much we can do to fix this issue on our side.

@NandoTheessen
Copy link
Author

Thanks, then this can be closed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
opensearch solved tech-issues The user has a technical issue about an application
Projects
None yet
Development

No branches or pull requests

3 participants