docs/proposal: add proposal for kubectl login #29350
Conversation
k8s-github-robot
added
kind/design
|
|
||
| ## Goals | ||
|
|
||
| `kubectl login` attempts to guide the user's experience when configuring |
There was a problem hiding this comment.
I think we want kubectl login to be the entry point for any user trying to connect to an existing server, not just for setting up the credential. I think you described that a bit following this, but I'd like to open with it.
|
I like the concept. Can you break down the phases you see? For instance, I think auto-discovery of auth providers is a natural phase-2. |
|
Proposal updated |
|
cc @robszumski please comment if you have any design points |
|
|
||
| However `kubectl login` should still be seen as a supplement to, not a | ||
| replacement for, `kubectl config` by helping validate any kubeconfig generated | ||
| by the latter command. |
There was a problem hiding this comment.
I don't foresee this being a connection that a typical user would make, unless explicitly told to do so in a blog/guide/doc. Definitely, not a blocker or anything though. Just a nice enhancement.
There was a problem hiding this comment.
Largely just a debugging mechanism. When you turn on authz, it's hard to tell if a user has misconfigured creds or incorrect access. kubectl login could immediately tell you one or the other.
ericchiang
force-pushed
the
kubectl-login-proposal
branch
2 times, most recently
from
e45dd1b
to
23a7161
Compare
|
Build finished. 3522 tests run, 15 skipped, 0 failed. |
|
@smarterclayton and @erictune does this version of the proposal look reasonable? |
|
|
||
| To help `kubectl login` diagnose mis-configured credentials, responses from the | ||
| API server to authenticated requests will include the `Authentication-Info` | ||
| header as defined in [RFC 7615](https://tools.ietf.org/html/rfc7615). The value |
There was a problem hiding this comment.
Should this be "MUST" or "SHOULD"? I.e. when there's a proxy server doing auth, and it doesn't set this, does login have to tolerate that?
There was a problem hiding this comment.
"SHOULD"? I could see use cases where admins don't actually want you to be able to differentiate between a failed login and an authorization denial.
|
I like this. |
|
@cjcullen your thoughts on how this proposal would relate to |
|
|
||
| ## Examples | ||
|
|
||
| If kubeconfig isn't configured, `kubectl login` will attempt to fully configure |
There was a problem hiding this comment.
I would prefer (but interested in other's opinions) that login also support flags for answering all of the questions below - in general I think it should be possible for a client to script "login" correctly without future changes causing failures. I.e.:
kubectl login -u user -p $PASSWORD
should never prompt the user for server info, because the user is in a non-interactive context. Alternatively, we can say "no, this is something that kubectl config is for" (if it's possible to do all the setup that login will do w.r.t. kerberos or oidc).
Either way, we should call it out here.
There was a problem hiding this comment.
kubectl config already has a lot of these options, so I don't know if we want to replicate effort here as well. For now, I think kubectl login should fail if it needs to prompt and isn't in an interactive session by printing a recommendation to use kubectl config.
I imagine experienced users will still prefer kubectl config with kubectl login only being used for final challenges (like a token exchange or password/username validation).
|
Few more small comments, everything else looks good. |
|
lgtm once suggested additions are in. |
ericchiang
force-pushed
the
kubectl-login-proposal
branch
from
61cc3b0
to
5a89b84
Compare
|
Small updates and added a small section about non-interactive sessions. |
|
No further comments, I'm fine with the answers above. LGTM as well. On Thu, Aug 4, 2016 at 4:57 PM, Kubernetes Bot notifications@github.com
|
| Logged in as "janedoe@gmail.com" | ||
| ``` | ||
|
|
||
| Users who wish to switch servers can provide the `--switch-cluster` flag which |
There was a problem hiding this comment.
not a big deal, but perhaps something like --prompt-cluster would be better, you might not end up switching clusters. can discuss further in the impl PR
There was a problem hiding this comment.
--reprompt, --reprompt-cluster and --reprompt-user? Is "reprompt" a word?
|
Given lgtm from @smarterclayton & @erictune I'm ready to LGTM this. @liggitt do you want anymore changes before merge? |
|
Ok, folks have had enough time, and its just a proposal. LGTM |
brendandburns
added
lgtm
|
GCE e2e build/test passed for commit 5a89b84. |
|
Automatic merge from submit-queue |
…posal Automatic merge from submit-queue docs/proposal: add proposal for kubectl login This PR updates kubernetes/enhancements#32 and kubernetes#25758 by adding a proposal for a "kubectl login" command. It's a bit more involved than the implementation discussed with @deads2k in kubernetes#25758, by proposing a long term goal for the overall subcommand. cc @kubernetes/sig-auth @kubernetes/kubectl
This PR updates kubernetes/enhancements#32 and #25758 by adding a proposal for a "kubectl login" command.
It's a bit more involved than the implementation discussed with @deads2k in #25758, by proposing a long term goal for the overall subcommand.
cc @kubernetes/sig-auth @kubernetes/kubectl
This change is