kubectl config: no commands to manage users

Created on 4 Apr 2018  Â·  28Comments  Â·  Source: kubernetes/kubectl

kubectl v1.10.0
/kind feature
/sig cli

kubectl config command lets users create/delete/update "context"s. Contexts are composed of "cluster"s and "user"s. Example:

contexts:
- name: my-context
  context:
    cluster: my-cluster-name
    user: my-user

kubectl config lets you create/update/delete "cluster"s, but IT DOESN'T let you manage "user"s:

Available Commands:
  current-context Displays the current-context
  delete-cluster  Delete the specified cluster from the kubeconfig
  delete-context  Delete the specified context from the kubeconfig
  get-clusters    Display clusters defined in the kubeconfig
  get-contexts    Describe one or many contexts
  rename-context  Renames a context from the kubeconfig file.
  set             Sets an individual value in a kubeconfig file
  set-cluster     Sets a cluster entry in kubeconfig
  set-context     Sets a context entry in kubeconfig
  set-credentials Sets a user entry in kubeconfig
  unset           Unsets an individual value in a kubeconfig file
  use-context     Sets the current-context in a kubeconfig file
  view            Display merged kubeconfig settings or a specified kubeconfig file

Why is that?

I think *-cluster commands listed above should also exist for *-user.

arekubectl kinfeature prioritbacklog sicli

Most helpful comment

kubectl config unset users.NAME.

I can understand how it may be more obvious if there were (delete/get/set) *-user(s) commands to match the existing *-cluster(s) and *-context(s) ones, but unset works for deleting user entries and is just as easy to type ¯\_(ツ)_/¯

All 28 comments

set-credentials configures the user entries

/reopen
@liggitt I don’t see a command to delete the user entries?

kubectl config unset users.NAME.

I can understand how it may be more obvious if there were (delete/get/set) *-user(s) commands to match the existing *-cluster(s) and *-context(s) ones, but unset works for deleting user entries and is just as easy to type ¯\_(ツ)_/¯

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

/area kubectl
@ahmetb Can we close this?

/remove-lifecycle rotten

@seans3 I'm not sure. I think the lack of user commands still cause symmetry and people need to find hacks like the one mentioned in https://github.com/kubernetes/kubectl/issues/396#issuecomment-389919197 (it probably got so many upvotes from people coming here via Google search results).

Thanks to the absence of a command to delete a user credentials, I had to:

  • search the web using DontBeEvilEvenIfIMayBeGoogle
  • read this thread to the bottom
  • try a few commands until I got the syntax right
  • make a note in a help file on how to delete a user credentials so that I won't have to search for it again
  • write this comment

To delete a user I used the command:
kubectl config unset users.<user-name>

I dunno, doesn't seem too hard to get a list of users. All I had to do was:
kubectl config view | yaml json write - | jq -r '.users[].name'
... and there you go, easy list of users. /s

doesn't seem too hard to get a list of users

Nobody claimed it's hard to "list" users (which comment are you replying to?). You can apply to the same to cluster and context resources, but we have get-clusters and get-contexts commands respectively –so this issue petitions for symmetry.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Anybody stumbling upon this issue from Google looking for an easy way to see all the users that doesn't have external dependencies, this will do it just fine:

kubectl config view -o jsonpath='{range .users[*]}{.name}{"\n"}{end}'

You can then use that in conjunction with the earlier command for kubectl config unset users.<user-name>

/remove-lifecycle stale

I would also appreciate something like

kubectl delete context --gc <context-name>

which would check the associated user and cluster, and also delete either or both of those if they are not in use from any other context. Basically a single command to undo the additions made by the likes of gcloud container clusters create. Krew plugin perhaps?

Yes that’s more suitable for a plugin.
Krew has a “config-cleanup” plugin. I recommend checking out.

So, how could we promote movement forward? Are we waiting on a discussion/decision? Would PRs be accepted?

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Krew has a “config-cleanup” plugin. I recommend checking out.

I did look at this but still feel that something like https://github.com/kubernetes/kubectl/issues/396#issuecomment-529471691, deleting specific users/contexts/etc., would be more comfortable: the cleanup plugin requires that you do some preconfiguration to make sure it is not throwing out some things that are still useful. (In my case, I have some EKS configurations that do not work unless I have recently refreshed a session token, a Microk8s configuration that does not work unless that service is currently running, etc.)

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

/remove-lifecycle rotten

/assign

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale

To me it seems obvious that there's 2 missing commands... this is part of the output from just running kubectl config:

delete-cluster Delete the specified cluster from the kubeconfig
delete-context Delete the specified context from the kubeconfig

get-clusters Display clusters defined in the kubeconfig
get-contexts Describe one or many contexts

set-cluster Sets a cluster entry in kubeconfig
set-context Sets a context entry in kubeconfig
set-credentials Sets a user entry in kubeconfig

/priority backlog

Was this page helpful?
0 / 5 - 0 ratings