Reputation: 759
I know role is used to grant permission to users or service account to perform operation in specific namespace.
A typical role definition may be like this
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: mynamespace
name: my-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
but in definition of service account, we can also see the namespace field
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-serviceac
namespace: mynamespace
My questions are:
1. Is namespace scope applied to user/service account or role?
2. what if the namespace in service account and role are different
role binding definition for reference
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: my-rolingbinding
namespace: mynamespace
subjects:
- kind: ServiceAccount
name: my-serviceac
namespace: mynamespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: my-role
Upvotes: 0
Views: 812
Reputation: 44559
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: mynamespace
name: my-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-serviceac
namespace: default
kubectl create rolebinding my-role-binding --role=my-role --serviceaccount=default:myserviceac -n mynamespace
And then checked the permission of the service account
kubectl auth can-i get pods -n mynamespace --as=system:serviceaccount:default:myserviceac
yes
kubectl auth can-i watch pods -n mynamespace --as=system:serviceaccount:default:myserviceac
yes
kubectl auth can-i list pods -n mynamespace --as=system:serviceaccount:default:myserviceac
yes
kubectl auth can-i get pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i list pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i watch pods -n default --as=system:serviceaccount:default:myserviceac
no
As we can see the service account has got permission to get,watch,list pods in mynamespace but does not have same permission in default namespace although the service account is located in default namespace.
Now if I delete the rolebinding and create it in default namespace instead of mynamespace.
kubectl create rolebinding my-role-binding --role=my-role --serviceaccount=default:myserviceac -n default
kubectl auth can-i get pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i list pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i watch pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i get pods -n mynamespace --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i list pods -n mynamespace --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i watch pods -n mynamespace --as=system:serviceaccount:default:myserviceac
no
As it can be seen that the permission is not applied anymore.
Upvotes: 2
Reputation: 2299
Service Account as Role resources are namespace-scoped: this allows to restrict specific actions to the given authenticated user (in this example, the Service Account) according to a Role.
Since we're talking about RBAC, you need a third resource to bind specific Role resources to a given Service Account: here comes the Role Binding, another namespace-scoped resource that maps these policies to a given set of users.
Since all these three components are strictly namespaces, all of them must live in the same namespace: otherwise, referencing the Service Account wouldn't work.
Upvotes: 1