Base64 decode fails with certificates that contain '=' sign

[javierholguera]

When configuring a cluster_ca, the resource is passing it through these lines:

    ca_path="/root/.kube/ca.pem"
    echo "$cluster_ca" | base64 -d > $ca_path
    kubectl config set-cluster default --server=$cluster_url --certificate-authority=$ca_path

Unfortunately, if the certificate contains '=' characters (used for padding), base64 complains about it. I'm not entirely sure why it fails, to be fair.

I found out after hijack-ing into the container. If instead of using a base64-decoded certificate, I call the same kubectl config command with the path to a base64-encoded certificate, it works fine.

If I remove the '=' sign at the end of the certificate, base64 works fine, but I get an error down the line like this:

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.4", GitCommit:"5ca598b4ba5abb89bb773071ce452e33fb66339d", GitTreeState:"clean", BuildDate:"2018-06-06T08:13:03Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Unable to connect to the server: x509: certificate signed by unknown authority

A bit of a chicken-and-problem. Any thoughts?

[msiegenthaler]

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?

[javierholguera]

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.

[danielsand]

@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