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.

Sign up for GitHub

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

Jump to bottom

Kubectl doesn't respect --user parameter when execution create clusterrolebinding #188

Closed
mpashka opened this issue Dec 22, 2017 · 11 comments
Closed

Kubectl doesn't respect --user parameter when execution create clusterrolebinding #188

mpashka opened this issue Dec 22, 2017 · 11 comments
Assignees
@liggitt

Comments

@mpashka
Copy link

mpashka commented Dec 22, 2017

Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.):
no

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.):
username

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT

What happened:
If <default_user> is configured in kubectl. When applying kubectl command with another user:
kubectl --user='admin' create clusterrolebinding <role_name> --clusterrole=view --group=<group_name>
Kubectl ignores --user parameter. And I get error
Error from server (Forbidden): User "<default_user>" cannot create clusterrolebindings...

What you expected to happen:
This should result in creating appropriate clusterrolebinding on behalf of admin user.
admin user is to be used for api server authentication, not viewer.

How to reproduce it (as minimally and precisely as possible):
Setup kubernetes cluster.

Configure kubectl. Create cluster configuration, context, 2 users, set default context. To reproduce this issue create two users in kubectl config - one user with permissions to create clusterrolebinding (admin) and another without (viewer). Set user without permissions (viewer) as default for context.

Apply kubectl create clusterrolebinding with different user specified. E.g.
kubectl --user='admin' create clusterrolebinding <role_name> --clusterrole=view --group=<group_name>

Instead of successfully created clusterrolebinding I get error message:
Error from server (Forbidden): User "viewer" cannot create clusterrolebindings.rbac.authorization.k8s.io at the cluster scope. (post clusterrolebindings.rbac.authorization.k8s.io)

Anything else we need to know?:
There are at least 2 workarounds:
Specify admin user as default in kubectl config
Create file with clusterrolebinding and apply kubectl create -f <file_name>

Kubernetes version (use kubectl version):
I checked this with kubectl 1.7.11 and 1.9.0
Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.4", GitCommit:"793658f2d7ca7f064d2bdf606519f9fe1229c381", GitTreeState:"clean", BuildDate:"2017-08-17T08:48:23Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.11", GitCommit:"b13f2fd682d56eab7a6a2b5a1cab1a3d2c8bdd55", GitTreeState:"clean", BuildDate:"2017-11-25T17:51:39Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
@mpashka mpashka mentioned this issue Dec 22, 2017
Closed
@apelisse apelisse added bug help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels Jan 2, 2018
@apelisse
Copy link
Member

apelisse commented Jan 2, 2018

If someone wants to look at that, they are very welcome

@Lion-Wei
Copy link

Lion-Wei commented Jan 8, 2018

I think we may have some misunderstanding here. IIUR, --user flag is the username you want to bind to the role, not the user name you use to create the clusterrolebinding.

@apelisse
Copy link
Member

apelisse commented Jan 8, 2018

IIUR, --user flag is the username you want to bind to the role, not the user name you use to create the clusterrolebinding.

I don't think that is true. --user is a global kubectl option, which on top of that is documented as follow:

--user='': The name of the kubeconfig user to use

I think it should do what @mpashka expects.

@Lion-Wei
Copy link

Lion-Wei commented Jan 9, 2018

But in create clusterrolebinding subcommand, the --user flag described as Usernames to bind to the role.
https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/create_clusterrolebinding.go#L57.
I'm not sure about that.

@Lion-Wei
Copy link

Lion-Wei commented Jan 9, 2018 •
edited
Loading

I have tested, the kubectl create clusterrolebinding command also have --user flag, which is conflict with the global --user option. We can solve this problem by change the --user flag of `kubectl create clusterrolebinding' to another name.
Here are my test result:

# k create clusterrolebinding test --user=lw --clusterrole=view 
clusterrolebinding "test" created
# k describe clusterrolebinding  test
Name:         test
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  view
Subjects:
  Kind  Name  Namespace
  ----  ----  ---------
  User  lw    

# ./kubectl create clusterrolebinding test1 --user=default --clusterroleuser=lw --clusterrole=view
error: auth info "default" does not exist

Here I changed this flag name to --clusterroleuser. : )

@Lion-Wei Lion-Wei mentioned this issue Jan 9, 2018
Closed
@apelisse
Copy link
Member

apelisse commented Jan 9, 2018 •
edited
Loading

I'm a little worried about the conflict. I don't think this should happen. Your patch is merely hiding the bug, isn't it? That might be a good thing, but it's probably too early to decide to do that.

Could you investigate how a global flag can conflict with a much deeper sub-command flag? That looks like a source of confusion.

@Lion-Wei
Copy link

Lion-Wei commented Jan 10, 2018 •
edited
Loading

Could you investigate how a global flag can conflict with a much deeper sub-command flag?

Sorry, I don't understand, I mean we have species of global flag and sub-command flag, but when we using the command, we can't specify use a flag as global flag or sub-command flag, if both of them have a same flag, then have some problem.
I think we need to discuss how to handler this situation, here I have some thoughts:

  1. Can we have a system to detect this case? I do think this should be avoid in coding.
  2. In this case, what should we do? Use this flag as global flag/sub-command flag/or both.
  3. Maybe error out?

@liggitt
Copy link
Member

liggitt commented Jan 15, 2018

the sub-command wins in this case. Having had that command available for several releases, I don't think we'll change the interface at this point

/close

@shiywang shiywang removed the help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. label Jan 17, 2018
@apelisse
Copy link
Member

@liggitt, are you saying that the person needs to change the active user in the kubeconfig to do that?

@liggitt
Copy link
Member

liggitt commented Jan 19, 2018

@liggitt, are you saying that the person needs to change the active user in the kubeconfig to do that?

yes, or define a context that references the desired user and use --context

@apelisse
Copy link
Member

Great, I think that's useful for the record :-)

This was referenced May 30, 2018
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@liggitt liggitt

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix '--user' flag conflict in create rolebinding command
6 participants
@liggitt @apelisse @shiywang @mpashka @k8s-ci-robot @Lion-Wei