Closed mwipplinger-ftapi closed 5 months ago
Hi there,
I also wanted to implement this functionality. I actually downloaded the helm chart and made the changes there, so now I'm using a preexisting secret to provide the credentials. However, I decided that I wanted to colaborate to this project.
The PR is good but in order for the change to work properly, we should also modify the deployment template so the environment variables of the container are grabbed from the existing secret. I tried to push the changes that I'm mentioning but I don't have write permission in the project (or maybe I don't know how to make a push to the repository properly, this is the first time that I contribute in GitHub). In any case, these are the changes that I wanted to propose:
values.yaml
#....rest of manifest...
openstack:
# You can provide the credentials through a preexisting secret (state the name of the secret in the field 'openstack.existingSecretName') or by stating them in plain text in the
# fields 'openstack.projectId', 'openstack.username' and 'openstack.password'. If a preexisting secret is specified, the fields 'openstack.projectId', 'openstack.username' and
# 'openstack.password' will be ignored. If you decide to use a preexisting secret, you can use the following template:
#apiVersion: v1
#kind: Secret
#metadata:
# name: <secret_name>
#type: Opaque
#stringData:
# OS_USERNAME: <plain_text_username>
# OS_PASSWORD: <plain_text_os_password>
# OS_PROJECT_ID: <plain_text_project_id>
existingSecret: ""
projectId: ""
username: ""
password: ""
deployment.yaml
#...rest of manifest...
envFrom:
- secretRef:
{{- if not .Values.openstack.existingSecret }}
name: {{ template "syseleven-exporter.secret" . }}
{{- else }}
name: {{ .Values.openstack.existingSecret }}
{{- end }}
#...rest of manifest
After doing this change, the helm chart worked for me as expected.
Hi there, you went with a different approach on how to configure the existing secret via changing the deployment template while I changed the template function that is used by the deployment to figure out the secret name that includes it's credentials. AFAIK both ways will work, it's just a matter of preference I suppose. As your proposed changes are functionally identical to mine I will refrain from refactoring them in. If the maintainers of this Chart ever come back to this repository and don't like the way I implemented that feature they may take your suggestion so thank you for reaching out and commenting on this PR!
Hi @mwipplinger-ftapi,
Alright, I didn't see in your PR that you modified the template function =) Let's hope that the maintainers take a look eventually at this PR and merge it. In any case, thanks for your contribution
To be able to use this chart securely with gitOps tooling the ability to use existing secrets that are created via gitOps and encrypted in the repositories to not expose secret information is crucial. We'd like to introduce this feature to this helm chart. The external Secret config would be optional and should not introduce changes for users of the chart that use the current configuration possibilities