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
Presence of bearer token should cancel exec action #91745
Conversation
Hi @anderseknert. Thanks for your PR. I'm waiting for a kubernetes 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 @liggitt |
4bf8456
to
27803bf
Compare
/unassign |
/remove-sig api-machinery |
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.
LGTM, but I would like to see a kubectl get --token $TOKEN pods
style test to prove that this actually overrides the exec
plugin in the way that we expect it to.
/ok-to-test |
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.
Minor comments.
Added pre-condition check for client certificate authentication capabilities and a test without |
Integration tests not giving the same output on the CI server as on my local machine. Will look into it further tomorrow. |
If a bearer token is present in a request, the exec credential plugin should accept that as the chosen method of authentication. Judging by an [earlier comment in exec.go](https://github.com/kubernetes/kubernetes/blob/c18bc7e9f7a27d7d197053d98c52896e1dc3bb3e/staging/src/k8s.io/client-go/plugin/pkg/client/auth/exec/exec.go#L217), this was already intended. This would however not work since UpdateTransportConfig would set the GetCert callback which would then get called by the transport, triggering the exec plugin action even with a token present in the request. See linked issue for further details. See kubernetes#87369 for further details. Signed-off-by: Anders Eknert <anders.eknert@bisnode.com>
OK @enj - now working both locally and on CI server. I've rebased from master and squashed the commits. Quite a process for adding a nil return to a function 😄 But feels good to have this well covered! Thanks for guiding me along the way 👍 |
/lgtm 🎉
I think you just described making literally any change to
My pleasure! |
/retest |
@liggitt this is ready for you now. |
test/cmd/authentication.sh
Outdated
### Without provided --token, the exec credential plugin should be triggered | ||
# Pre-condition: Client certificate authentication enabled on the API server - already checked by positive test above | ||
|
||
kube_flags_without_token=('-s' "https://127.0.0.1:${SECURE_API_PORT}" '--insecure-skip-tls-verify=true') |
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.
nit: defining this far away from kube_flags_with_token
is not ideal... it places assumptions about the secured endpoint/port far away from where we actually start the server
options:
- define this in the same place we define
kube_flags_with_token
(and maybe rename it to make it clear the distinction is that it is pointing at a secured endpoint, e.g.kube_flags_secure_without_token
) - use
kube_flags_with_token
and then append another--token=
arg to clear out the token
I have a slight preference for 1
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 agree on moving it next to kube_flags_with_token
, and I'll do so. However, kube_flags_with_token
also uses the secure port, so I'm not sure about including secure
in the without_token
version. Did you think of kube_flags
which is defined next to it, and uses the insecure port?
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.
Or you meant renaming both of them? Anyway, I've moved them so that they're next to each other, with the with_token
version simply concatenating the token to the without_token
values.
// also configured to allow client certificates for authentication. For requests | ||
// like "kubectl get --token (token) pods" we should assume the intention is to | ||
// use the provided token for authentication. | ||
if c.HasTokenAuth() { |
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.
if we already have a client cert/key, should that take precedence as well and prevent calling the exec plugin?
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 think that makes sense, yes. This PR addressed a real problem we experienced with our exec plugin using tokens, and the client certificate scenario wasn't something I considered - I don't even know what the current behavior there is to be honest, but I could certainly look into supporting that case as well if you want. With that said, I think the single argument of --token
makes it a lot more likely to be used ad-hoc than client certificates, which requires something like three(?) file locations to be provided.
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 think the current state of the PR is coherent w.r.t. token auth. A follow up issue to discuss/resolve treatment of client cert auth is fine with me
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.
/lgtm
/approve
/retest
// also configured to allow client certificates for authentication. For requests | ||
// like "kubectl get --token (token) pods" we should assume the intention is to | ||
// use the provided token for authentication. | ||
if c.HasTokenAuth() { |
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 think the current state of the PR is coherent w.r.t. token auth. A follow up issue to discuss/resolve treatment of client cert auth is fine with me
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: anderseknert, liggitt The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
/retest Review the full test history for this PR. Silence the bot with an |
/retest |
2 similar comments
/retest |
/retest |
What type of PR is this?
/kind bug
What this PR does / why we need it:
If a bearer token is present in a request/config, the exec credential plugin should accept that as the chosen method of authentication. Judging by an earlier comment in exec.go, this was already the intention. This would however not work since
UpdateTransportConfig
would set theGetCert
callback which would then get called by the transport, triggering the exec plugin action even with a token present in the request. See linked issue for further details.Which issue(s) this PR fixes:
Fixes #87369
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
Signed-off-by: Anders Eknert anders.eknert@bisnode.com