9

I know there are a lot of similar questions but none of them has a solution as far as I have browsed. Coming to the issue, I have created a service account (using command), role (using .yaml file), role binding (using .yaml files). The role grants access only to the pods. But when I login into the dashboard (Token method) using the SA that the role is attached to, I'm able to view all the resources without any restrictions. Here are the file and commands used by me.

Role.yaml:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: assembly-prod
  name: testreadrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

RoleBinding.yaml

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: testrolebinding
  namespace: assembly-prod
subjects:
- kind: ServiceAccount
  name: testsa
  apiGroup: ""
roleRef:
  kind: Role
  name: testreadrole
  apiGroup: rbac.authorization.k8s.io

Command used to create service account: kubectl create serviceaccount <saname> --namespace <namespacename>

UPDATE: I create a service account and did not attach any kind of role to it. When I tried to login with this SA, It let me through and I was able to perform all kinds activities including deleting "secrets". So by default all SA are assuming admin access and that is the reason why my above roles are not working. Is this behavior expected, If yes then how can I change it?

vishal
  • 1,646
  • 5
  • 28
  • 56

3 Answers3

8

Try the below steps

# create service account
kubectl create serviceaccount pod-viewer

# Create cluster role/role
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-viewer
rules:
- apiGroups: [""] # core API group
  resources: ["pods", "namespaces"]
  verbs: ["get", "watch", "list"]
---

# create cluster role binding
kubectl create clusterrolebinding pod-viewer \
  --clusterrole=pod-viewer \
  --serviceaccount=default:pod-viewer

# get service account secret
kubectl get secret | grep pod-viewer
pod-viewer-token-6fdcn   kubernetes.io/service-account-token   3      2m58s

# get token
kubectl describe secret pod-viewer-token-6fdcn
Name:         pod-viewer-token-6fdcn
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: pod-viewer
              kubernetes.io/service-account.uid: bbfb3c4e-2254-11ea-a26c-0242ac110009

Type:  kubernetes.io/service-account-token

Data
====
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InBvZC12aWV3ZXItdG9rZW4tNmZkY24iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoicG9kLXZpZXdlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImJiZmIzYzRlLTIyNTQtMTFlYS1hMjZjLTAyNDJhYzExMDAwOSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OnBvZC12aWV3ZXIifQ.Pgco_4UwTCiOfYYS4QLwqgWnG8nry6JxoGiJCDuO4ZVDWUOkGJ3w6-8K1gGRSzWFOSB8E0l2YSQR4PB9jlc_9GYCFQ0-XNgkuiZBPvsTmKXdDvCNFz7bmg_Cua7HnACkKDbISKKyK4HMH-ShgVXDoMG5KmQQ_TCWs2E_a88COGMA543QL_BxckFowQZk19Iq8yEgSEfI9m8qfz4n6G7dQu9IpUSmVNUVB5GaEsaCIg6h_AXxDds5Ot6ngWUawvhYrPRv79zVKfAxYKwetjC291-qiIM92XZ63-YJJ3xbxPAsnCEwL_hG3P95-CNzoxJHKEfs_qa7a4hfe0k6HtHTWA
ca.crt:     1025 bytes
namespace:  7 bytes
```

Login to dashboard using the above token. you should see only pods and namespaces

[![Refer the below link][1]][1]


  [1]: https://i.stack.imgur.com/D9bDi.png
P Ekambaram
  • 15,499
  • 7
  • 34
  • 59
3

I see that the .yamls you provided need some adjustments.

Role has wrong formatting after the rules part.

RoleBinding is missing namespace: after subjects:, and also is formatted wrongly.

Try something like this:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: assembly-prod
  name: testreadrole
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: testrolebinding
  namespace: assembly-prod
subjects:
  - kind: ServiceAccount
    name: testsa
    namespace: assembly-prod
roleRef:
  kind: Role
  name: testreadrole
  apiGroup: rbac.authorization.k8s.io

There is a very useful guide about Non-Privileged RBAC User Administration in Kubernetes where you can find more detailed info regarding this particular topic.

Arghya Sadhu
  • 41,002
  • 9
  • 78
  • 107
Wytrzymały Wiktor
  • 11,492
  • 5
  • 29
  • 37
  • No luck. I'm still able to see everything. What am I possibly doing wrong? Does all service accounts by default have any admin access anything? I really don't know what I'm missing here because I don't see an error too. – vishal Dec 17 '19 at 06:56
  • As told in the article provided: `while they were technically using RBAC to create users, they were simply giving those users full administrative access. ` Have you tried to go step by step as described within the guide? Because I was not able to reproduce your issue. – Wytrzymały Wiktor Dec 17 '19 at 09:04
  • I went through the doc and did the exact same thing but still the same situation. Could this be related to my dashboard version or something like that? The hard-point here is there are no errors too. – vishal Dec 18 '19 at 09:35
  • I've raised a bounty and have also updated a few things. See If it helps. – vishal Dec 19 '19 at 05:13
  • Have you tried to create Roles and Rolebidings by using [commands](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-role-em-) instead of manually creating .yaml files? – Wytrzymały Wiktor Dec 19 '19 at 10:16
  • Will that really make any difference? – vishal Dec 20 '19 at 12:28
  • Yes. It diminishes the possibility of errors in manually generated `yamls` and also helps us analyze your issue. Please provide the info I have asked for. – Wytrzymały Wiktor Dec 20 '19 at 13:21
3

Okay I've found the solution for this. The major issue was I'm running my cluster on Azure AKS, which I should have mentioned in the question but did not. It was my mistake. In Azure AKS, if rbac is not enabled during cluster creation, then there is no use of roles and role-bindings at all. All request to the api-server will be treated as requests from Admin. This was confirmed by Azure support too. So that was the reason my cluster-role-binding and roles didn't apply.

vishal
  • 1,646
  • 5
  • 28
  • 56