Kubernetes Tutorial doesn't work #4902
Comments
|
The kubernetes API server logs tell us why the certificate is considered invalid: This can be fixed by adding e.g. We'll need to update the config to use the SAN extension name rather than the common name. |
anderseknert
added a commit
to anderseknert/opa
that referenced
this issue
Jul 19, 2022
Two unrelated issues would break the Kubernetes tutorial in recent kube versions. The first one being the SHA1 hash used by default in at least older versions of OpenSSL, which is no longer accepted by Kubernetes. Easy fix. The next one is definitely a head scratcher - for whatever reason, the subjectAltName previously provided in the config didn't seem to be picked up in certificate signing requests. Older versions of Kubernetes - or Go, really - would accept the common name (CN), but more recent ones require the use of subjectAltName, so it's possible this never "worked" as intended but was ignored as the CN was used instead. The docs on the topic however all suggest that the previous config _should_ have worked, and after having spent a long time trying to figure out why it didn't, I've found nothing to provide any insights here. Best I have is "works on my machine", so if anyone else would want to try this out to make sureit works on theirs too, that'd be great. * Use explicit hashing algorithm * Specify -extensions as this does not seem to be picked up when provided in config only. Fixes open-policy-agent#4902 Signed-off-by: Anders Eknert <anders@eknert.com>
anderseknert
added a commit
that referenced
this issue
Jul 19, 2022
Two unrelated issues would break the Kubernetes tutorial in recent kube versions. The first one being the SHA1 hash used by default in at least older versions of OpenSSL, which is no longer accepted by Kubernetes. Easy fix. The next one is definitely a head scratcher - for whatever reason, the subjectAltName previously provided in the config didn't seem to be picked up in certificate signing requests. Older versions of Kubernetes - or Go, really - would accept the common name (CN), but more recent ones require the use of subjectAltName, so it's possible this never "worked" as intended but was ignored as the CN was used instead. The docs on the topic however all suggest that the previous config _should_ have worked, and after having spent a long time trying to figure out why it didn't, I've found nothing to provide any insights here. Best I have is "works on my machine", so if anyone else would want to try this out to make sureit works on theirs too, that'd be great. * Use explicit hashing algorithm * Specify -extensions as this does not seem to be picked up when provided in config only. Fixes #4902 Signed-off-by: Anders Eknert <anders@eknert.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Short description
Hello,
I tried to follow the kubernetes tutorial here. If i run
kubectl logs -l app=opa -c opa -fbefore I runkubectl apply -f webhook-configuration.yamlthe logs appear fine. If I then runkubectl apply -f webhook-configuration.yamlin a separate terminal session, the logs start showing errors like this:However, if i run
kubectl apply -f webhook-configuration.yamlbefore I check the logs (as per the tutorial), i get Authorization errors a few seconds after runningkubectl logs -l app=opa -c opa -f:I put all the steps from the tutorial in a bash script, which is in a repository I created here.
The complete logs from running my script is below:
Steps To Reproduce
Expected behavior
OPA starts without any auth/ssl issues
Additional context
services.default.urlin theadmission-controller.yamlfile tohttp://host.docker.internal:8888and I'm still getting Authorization errors.The text was updated successfully, but these errors were encountered: