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
✨ Envtest exports rest.Config for the secure endpoint of kube-apiserver #984
✨ Envtest exports rest.Config for the secure endpoint of kube-apiserver #984
Conversation
…onnect 'https' endpoint of kube-apiserver
Welcome @everpeace! |
Hi @everpeace. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/assign @droot |
/assign @alvaroaleman @DirectXMan12 |
Hi, I also had a need to do this, so I am using this branch and it is working well for me, thanks. |
/ok-to-test |
7db3b83
to
034f8e3
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: everpeace The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Please note that this just contains secure endpoint itself and its CA certs. User will have to set authentication information by themselves and configure some authn module in kube-apiserver.
034f8e3
to
7dd198f
Compare
I'm tempted to approve this as-is (it looks pretty reasonable), but it's also kind of a half-measure, due to forcing folks to override the apiserver flags, etc. Can we think of a good way around that? I've got a pretty complicated prototype hanging around over at #645 -- maybe we could adapt/simplify that? |
Yeah, it's a half-measure for testing with auth, but at least this allows for that testing to take place. Without this change users would have to resort to horrible hacks to get access to the secure port, even with overriding auth apiserver flags. What about merging this to at least make it possible to do these things, and then look at improvements to make it a better experience? |
I agree that it's kind of half-measure and this should be more simple. However, as james pointed out, users currently have heavy pain to access to a secure endpoint. So, I would like to add 👍 to james' idea. WDYT? |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/lifecycle stale |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am very sorry this didn't get any attention for so long, it appears I missed it in my queue :(
// te := &envtest.Environment{ | ||
// KubeAPIServerFlags: append( | ||
// envtest.DefaultKubeAPIServerFlags, | ||
// "--basic-auth-file=my-file", "--authorization-mode=RBAC", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@everpeace what about extending envtest to generate a token-auth-file
with a token that is member of the system:masters
group so this just works by default?
Also, a test would be great 🙃
If you do not have time to pick that up, we can also merge this as-is and I will address my comments in a follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alvaroaleman Thank you for your review!!
If you do not have time to pick that up, we can also merge this as-is and I will address my comments in a follow-up.
sorry... I couldn't spare time to do this currently. I'm very glad if we take this way 🙇 🙇
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alvaroaleman As I understand it you suggestion is just to provide a static user in the token-auth-file? I think it would be better to have an option to add individual users (maybe in addition to a default) so that you can specify particular groups that the user may be a member of.
One example of where this may be useful is testing CSRs, where the API server uses the requesting parties credentials to become part of the CSR request. Typically here you'd want to be able to specify the exact groups that the user belongs to to be able to get the right groups plumbed into that CSR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JoelSpeed you can just create a SA and then use impersonation for that. @DirectXMan12 is working on an updated version of this afaik
Works well for me. I applied this patch on 0.8.2 release, works as expected. |
/close |
fixes #983
This PR added:
internal.integration.APISever
: exposeTLSClientConfig
to connect its secure endpointenvtest.Environment
: introduceSecureConfig
that just contains kube-apiserver's secure endpoint and itsTLSClientConfig
.Note: To work with
SecureConfig
, users will have to set authn information like this.