Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to setup guard with private Gitlab and kube 1.19.7 #309

Open
irizzant opened this issue Jan 28, 2021 · 3 comments
Open

Unable to setup guard with private Gitlab and kube 1.19.7 #309

irizzant opened this issue Jan 28, 2021 · 3 comments

Comments

@irizzant
Copy link

irizzant commented Jan 28, 2021

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.

@mattlqx
Copy link

mattlqx commented Feb 17, 2021

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.

@irizzant
Copy link
Author

irizzant commented Feb 17, 2021

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

@kycfeel
Copy link

kycfeel commented Mar 30, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants