kubeguard / guard

🔑 Kubernetes Authentication & Authorization WebHook Server

Home Page:https://kubeguard.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unable to setup guard with private Gitlab and kube 1.19.7

irizzant opened this issue · comments

Hello
up to version 0.6.1 I was able to make Guard work with kube 1.18 and our private Gitlab.

After upgrading to 0.7.1 and kube 1.19.7 the authentication does not work anymore.

The apiserver reports

E0128 09:00:43.754283       1 authentication.go:53] Unable to authenticate the request due to an error: [invalid bearer token, Post "https://10.233.0.27:443/tokenreviews?timeout=30s": x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "ca")]

but I verified that the kubeconfig file generated for webhook auth used by the apiserver is the same as the one generated with

guard get webhook-config sdb -o gitlab --addr=10.233.0.27:443

Can you please help?

UPDATE:
After more tests, I got this error from the apiserver:

E0128 12:01:51.693364       1 webhook.go:111] Failed to make webhook authenticator request: converting (v1.TokenReview) to (v1beta1.TokenReview): unknown conversion
E0128 12:01:51.693396       1 authentication.go:53] Unable to authenticate the request due to an error: [invalid bearer token, converting (v1.TokenReview) to (v1beta1.TokenReview): unknown conversion]

Looks like Guard is not replying with the same TokenReview version as the request, violating this requirement from the official kubernetes doc:

Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should check the apiVersion field of the request to ensure correct deserialization, and must respond with a TokenReview object of the same version as the request.

Guard appears to be giving responses in v1 regardless, so with 1.19, you can opt into v1 requests with --authentication-token-webhook-version=v1 argument on the kube-apiserver as a workaround.

Thanks @mattlqx for the hint, I was aware of it anyway.
Nevertheless according to the official doc it's still something to be fixed in Guard, since implementors are expected to check the apiVersion on the requests and reply accordingly

I experienced something exactly the same with Kubernetes v1.23.

The kube-api was returning error something like below:

E0330 11:07:42.378929 1 webhook.go:155] Failed to make webhook authenticator request: the server has asked for the client to provide credentials
E0330 11:07:42.379004 1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, the server has asked for the client to provide credentials]"

I was able to solve it by adding the --authentication-token-webhook-version=v1 flag on the kube-api's yaml config file, as @mattlqx mentioned.

But as @irizzant said, I also believe that this is something the Guard should take care of by itself. The current way is just a "hack".

If it's something hard to get added right away, then at least it should be mentioned on the docs.