Kubernetes check serviceaccount permissions

Solution 1:

After trying lots of things and Googling all over the universe I finally found this blogpost about Securing your cluster with RBAC and PSP where an example is given how to check access for serviceaccounts.

The correct command is:
kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<namespace>:<serviceaccountname> [-n <namespace>]

To check whether the tiller account has the right to create a ServiceMonitor object:
kubectl auth can-i create servicemonitor --as=system:serviceaccount:staging:tiller -n staging

Note: to solve my issue with the tiller account, I had to add rights to the servicemonitors resource in the monitoring.coreos.com apiGroup. After that change, the above command returned yes (finally) and the installation of our Helm Chart succeeded.

Updated tiller-manager role:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tiller-manager
  labels:
    org: ipos
    app: tiller
  annotations:
    description: "Role to give Tiller appropriate access in namespace"
    ref: "https://docs.helm.sh/using_helm/#example-deploy-tiller-in-a-namespace-restricted-to-deploying-resources-only-in-that-namespace"
rules:
- apiGroups: ["", "batch", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups:
    - monitoring.coreos.com
  resources:
    - servicemonitors
  verbs:
    - '*'

Solution 2:

this displays what permissions you have on a service account prom-stack-grafana: e.g.

kubectl -n monitoring auth can-i --list --as=system:serviceaccount:monitoring:prom-stack-grafana

Solution 3:

Note: kubectl auth can-i command has an edge case / gotcha / mistake to avoid worth being aware of.
Basically a user can be named with a similar syntax to a service account, and it can trick it.
It had me tripped up for quite a while so I wanted to share it.

alias k=kubectl
k create ns dev 
k create role devr --resource=pods --verb=get -n=dev 
k create rolebinding devrb --role=devr --user=system:serviceaccount:dev:default -n=dev # wrong syntax 
k auth can-i get pods -n=dev --as=system:serviceaccount:dev:default  # right syntax
# yes 

(The fact that k auth can-i said yes made me think my rolebinding was correct syntax, but it's wrong)

This is correct:

k delete ns dev
k create ns dev 
k create role devr --resource=pods --verb=get -n=dev 
k create rolebinding devrb --role=devr --serviceaccount=dev:default -n=dev # right syntax 
k auth can-i get pods -n=dev --as=system:serviceaccount:dev:default  # right syntax
# yes

Here is visual proof of how it's wrong:

k create rolebinding devrb1 --role=devr --user=system:serviceaccount:dev:default -n=dev --dry-run=client -o yaml | grep subjects -A 4
# subjects:
# - apiGroup: rbac.authorization.k8s.io
#   kind: User
#   name: system:serviceaccount:dev:default

k create rolebinding devrb2 --role=devr --serviceaccount=dev:default -n=dev --dry-run=client -o yaml | grep subjects -A 4
# subjects:
# - kind: ServiceAccount
#   name: default
#   namespace: dev

If ever in doubt about syntax for imperative rbac commands, here's a fast way to look it up:

1. kubernetes.io/docs
2. search "rbac"
3. control+f "kubectl create rolebinding" on the page to get example of correct syntax.