Am trying to better understand RBAC in kubernetes. Came across this unexpected situation where authorization test using kubectl auth can-i
and actual results are different. In short, newly created user should not be able to get pods as per this test, however this user can actually get pods.
Version:
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac55d903350454310a", GitTreeState:"clean", BuildDate:"2018-07-17T18:53:20Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"b1b29978270dc22fecc592ac55d903350454310a", GitTreeState:"clean", BuildDate:"2018-07-17T18:43:26Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
kubectl config for user in questions:
$ kubectl config view --minify
apiVersion: v1
clusters:
- cluster:
certificate-authority: /home/master/ca.pem
server: https://192.168.1.111:6443
name: jdoe
contexts:
- context:
cluster: jdoe
user: jdoe
name: jdoe
current-context: jdoe
kind: Config
preferences: {}
users:
- name: jdoe
user:
client-certificate: /home/master/jdoe.pem
client-key: /home/master/jdoe-key.pem
The test against authorization layer says jdoe cannot get pods.
$ kubectl auth can-i get pods --as jdoe
no
However, jdoe can get pods:
$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
ingress-nginx nginx-ingress-controller-87554c57b-ttgwp 1/1 Running 0 5h
kube-system coredns-5f7d467445-ngnvf 1/1 Running 0 1h
kube-system coredns-5f7d467445-wwf5s 1/1 Running 0 5h
kube-system weave-net-25kq2 2/2 Running 0 5h
kube-system weave-net-5njbh 2/2 Running 0 4h
Got similar results from auth layer after switching back to admin context:
$ kubectl config use-context kubernetes
Switched to context "kubernetes".
$ kubectl config view --minify
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: REDACTED
server: https://192.168.1.111:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: admin
name: kubernetes
current-context: kubernetes
kind: Config
preferences: {}
users:
- name: admin
user:
client-certificate: /home/master/admin.pem
client-key: /home/master/admin-key.pem
From here too, user jdoe is not supposed to get pods.
$ kubectl auth can-i get pods --as jdoe
no
Output of kubectl config view
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority: /home/master/ca.pem
server: https://192.168.1.111:6443
name: jdoe
- cluster:
certificate-authority-data: REDACTED
server: https://192.168.1.111:6443
name: kubernetes
- cluster:
certificate-authority: /home/master/ca.pem
server: https://192.168.1.111:6443
name: master
contexts:
- context:
cluster: jdoe
user: jdoe
name: jdoe
- context:
cluster: kubernetes
user: admin
name: kubernetes
- context:
cluster: master
user: master
name: master
current-context: kubernetes
kind: Config
preferences: {}
users:
- name: admin
user:
client-certificate: /home/master/admin.pem
client-key: /home/master/admin-key.pem
- name: jdoe
user:
client-certificate: /home/master/jdoe.pem
client-key: /home/master/jdoe-key.pem
- name: master
user:
client-certificate: /home/master/master.pem
client-key: /home/master/master-key.pem
kubectl get pods
with no specific pod name actually does a list. See https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb for details about what verb corresponds to a given request.
What does can-i list pods
return?