Satyam Sareen:
Hi CKAers
I have created the below role:
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- replace
- list
- apiGroups:
- <http://networking.k8s.io|networking.k8s.io>
resources:
- networkpolicies
- pods
verbs:
- get
- replace
- list
as we can see that I have not given watch permissions, but still my user is able to perform the operation: watch k get po
Can someone pls tell me how the watch operation is working even though the required permissions are not there in the role
Thank you
R Banerjee:
Wouldnt the above rules allow get pods ?
Is the watch command using any secret from the default config file? It seems to be, because if k get po works without any client key/client crt , IMHO, the default config should work with the default SA which may be associated to the watch command
A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.
unnivkn:
could you please share your role & rolebinding. Also pls share this output: cat /etc/kubernetes/manifest/kube-apiserver.yaml | grep -i authorization-mode
R Banerjee:
Aah, thanks for the direction ( useful for future )
Satyam Sareen:
@unnivkn
shared the below details, i am still confused how watch command is working without the required permissions in my role
• role is shared above
• authorization-mode:
:~$ sudo cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep -i authorization-mode
- --authorization-mode=Node,RBAC
• rolebinding: (i have created this role for my user, which i use to access my cluster from a different server, kubeconfig file is already setup:
apiVersion: <http://rbac.authorization.k8s.io/v1|rbac.authorization.k8s.io/v1>
kind: RoleBinding
metadata:
creationTimestamp: "2021-08-29T22:23:46Z"
name: satyam-rb
namespace: default
resourceVersion: "125571"
uid: d2c0d270-1cf5-449c-b8e2-d9fd9988f7e2
roleRef:
apiGroup: <http://rbac.authorization.k8s.io|rbac.authorization.k8s.io>
kind: Role
name: satyam-role
subjects:
- apiGroup: <http://rbac.authorization.k8s.io|rbac.authorization.k8s.io>
kind: User
name: satyam
R Banerjee:
Question: You are running watch with the Satyam user?
R Banerjee:
Can you try with some other user?
Satyam Sareen:
I have two users currently admin and satyam
admin is the default user that kubeadm creates for us, the other one is a custom user that I am testing different policies on
R Banerjee:
I believe admin would have the default rights ( i.e. all ) and satyam has the specified rights on pods.
now the watch command is being used under the user satyam, so it should execute on pods easily
But I would like @unnivkn’s opinion about it
unnivkn:
no luck… not sure any issue with user creation.
unnivkn:
Could you please try with SA
Satyam Sareen:
@unnivkn, k auth can-i get pods --as satyam, should have returned “yes”, right?
but it didn’t:confused:
Satyam Sareen:
I think I found what was the issue
watch is a Linux command and so it is independent of the permissions in the satyam role
but if I do k get po --watch then I get a forbidden message
Error from server (Forbidden): unknown (get pods)
R Banerjee:
Running watch inside get pods, doesnt work, does it?
Update:
checked https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands , I could find --watch but its not associated with getting the pods, so I am not sure if this command may work normally either…
However, I think the check for you is working correctly at least for k get pods , without the watch command.
Even though watch is a Linux command, it is running in the same shell as your normal CLI commands, so ifthe user is Satyam who is running it, they may have the authority to do it.
I would still prefer experimenting with a Guest User and checking if they can watch the k get pods to see the logic of this issue
Satyam Sareen:
is there is difference between satyam and default:satyam
unnivkn:
yup… looks like in terms of role, rolebinding namespace makes some difference
