Open throwawayaccount0153 opened 2 years ago
we use it like this: in chart
flux2:
kustomizecontroller:
secret:
create: true
name: netrc
data:
.netrc: "machine gitlab.com \nlogin git \npassword password" ## multiline via \n
extraSecretMounts:
- name: netrc
mountPath: "/home/controller/.netrc"
subPath: .netrc
secretName: netrc
readOnly: true
in flux2-sync:
secret:
create: true
data:
username: gitlab-ci-token
password: password
we use it like this: in chart
flux2:
kustomizecontroller: secret: create: true name: netrc data: .netrc: "machine gitlab.com \nlogin git \npassword password" ## multiline via \n extraSecretMounts: - name: netrc mountPath: "/home/controller/.netrc" subPath: .netrc secretName: netrc readOnly: true
in flux2-sync:
secret: create: true data: username: gitlab-ci-token password: password
I'm using ssh so mine needs to look like this:
secret:
create: true
data:
identity: |
SSH__PRIVATE_KEY
identity.pub: |
SSH__PUBLIC_KEY
known_hosts: "GITHUB_KNOWN_HOSTS_ENTRY"
this is the reason for the bug report, most people use ssh and not https, so we need a mutli line block
When people argue with "most people", I am always interested in getting the link to a statistic or real evidence ;-)
Beside that. I tried your approch and it works for me.
values.yaml:
secret:
create: true
data:
identity: |
SSH__PRIVATE_KEY
asdfasdfasdf
identity.pub: |
SSH__PUBLIC_KEY
22222
4444444
known_hosts: "GITHUB_KNOWN_HOSTS_ENTRY"
Results in:
data:
identity: U1NIX19QUklWQVRFX0tFWQphc2RmYXNkZmFzZGYK
identity.pub: U1NIX19QVUJMSUNfS0VZCjIyMjIyCjQ0NDQ0NDQK
known_hosts: R0lUSFVCX0tOT1dOX0hPU1RTX0VOVFJZ
Which can be decoded to:
echo "U1NIX19QUklWQVRFX0tFWQphc2RmYXNkZmFzZGYK" | base64 -d
SSH__PRIVATE_KEY
asdfasdfasdf
So it works, I understand that you suggest an "examples" section, which would be a good idea. And we could start with the two examples mentioned here.
When people argue with "most people", I am always interested in getting the link to a statistic or real evidence
Given that Flux v1 supported only SSH for years and Flux v2 flux bootstrap
defaults to SSH deploy keys, I think “most people” is accurate. As for statistics, Flux is a CNCF project and we no longer collect stats from people’s clusters, but we used to do that for v1 and SSH was used by almost everyone.
@stefanprodan Thanks for the information. @throwawayaccount0153 Do I get it right, that it works, but you suggest to have an examlpe in the repo? (so its not actual bug)
@dwerder you are correct, it works, though via the mechanism I'm executing helm, via terraform, it turns out I needed to wrap these particular values in an indent(6, KEY) function in order to get it to work properly. otherwise outside of terraform this works just as we've tested. Yes, it would be nice to have an example, although a piped multiline value is standard helm so technically we'd be doubling helm documentation, but it would be nice for a quick reference for people who don't want to go search through helm documentation, they could just refer to an example solution here in a commented out block in the values file
Describe the bug a clear and concise description of what the bug is.
Please include a secret.data: {} example as I cannot get a secret to work. This is due to the fact that It doesn't appear that data: {} accepts a multi line string which is needed to accept an ssh private key, I don't believe json accepts multiline values. can this be changed to be more multi line string friendly?
What's your helm version?
latest stable
What's your kubectl version?
latest stable
What's the chart version?
latest stable
What happened?
json only accepts string
What you expected to happen?
I expect to be able to paste an ssh key in as a string in the value and have it work
How to reproduce it?
secret: create: true data: {"foo": "SSH KEY"}
Enter the changed values of values.yaml?
secret: create: true data: {} <-- this is the problem value
Enter the command that you execute and failing/misfunctioning.
i'm running via terraform via a helm_release resource but this is the same as the helm install command listed here
Anything else we need to know?
no