Base64 decode fails with certificates that contain '=' sign about concourse-helm-resource HOT 3 CLOSED

I'm not sure, but it sounds like the certificate is decoded twice, right? Because it work if you "skip" a decoding step.
What happens if you base64 encode the certificate in you pipeline.yaml?

from concourse-helm-resource.

I don't think the problem is related to double-decoding.

What I've tested is quite simple. I hijacked into the container, run base64 against the certificate (in base64 format) and it failed.

Then, edited the certificate, removed the '=' symbols, tried with base64 again and it worked. Why does busybox's base64 do this? I don't know, seems to me that using '=' symbols for padding is sort of a standard practice.

In any case, I don't think to decode the certificates from base64 is required to pass them to the various tools (helm, kubectl). That's what I'm doing now on a modified version of this resource, remove everything related to base64 decoding, to let the tools used the base64-codified version of the certificates, and it's working fine.

from concourse-helm-resource.

@javierholguera

this seems to be a problem by creating the secret via kubectl

if you dont use the --from-file parameter to feed the certificates as files into the secret - most likley it will fail.

in the end i put all 3 certificate snippets into files and loaded them via cli

kubectl create secret generic --namespace concourse-main k8s --from-file=cluster_ca=cluster_ca --from-file=admin_cert=admin_cert --from-file=admin_key=admin_key

i hope this might shed some light

from concourse-helm-resource.