x509: certificate relies on legacy Common Name field about tesoro HOT 6 OPEN

Looks like this is an issue with the v1.19 release of Kubernetes. Repeating the example with v1.18 worked as expected.

minikube start --driver docker --kubernetes-version=v1.18.12

Looks

• Kubernetes is now built with golang 1.15.0-rc.1 #93264

from tesoro.

kapicorp/kapitan-reference#37
I have fixed the template we use to generate the certificates

I will upload soon the corrected example files.

from tesoro.

meanwhile @myspotontheweb feel free to use the https://github.com/kapicorp/kapitan-reference/tree/master/compiled/tesoro version that should be also much easier to install (see kapicorp/kapitan-reference#37)

from tesoro.

I will take a look right away, thank you for the amazingly detailed issue report :)

from tesoro.

@ramaro my suggestion would be for the manifests here to match the ones from https://github.com/kapicorp/kapitan-reference/tree/master/compiled/tesoro, so that we can make it easier to regenerate.

In kapitan-reference I have used the name tesoro instead of tesoro-admission-controller for the webhook and the service (and the DNS name). Do you mind?

Also I have everything bundled up in a file instead of individual files for easier deployment.

Happy to generate ad-hoc certificates for the current naming you have in place, but I think we should direct people to kapitan-reference anyway.

What do you think?
See: #23

from tesoro.

hey @myspotontheweb , on this issue, I remember you suggested a much better approach at the time, but I cannot find where you wrote the suggestions. Did you remove the comment or did you write it somewhere else? on Slack perhaps?

from tesoro.