HKIT
HKIT

Reputation: 759

Namespace for User or Role in Kubernetes

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

Answers (2)

Arghya Sadhu
Arghya Sadhu

Reputation: 44559

  1. Namespace is applied to all three of role, service account and role binding.
  2. It does not matter if the namespace is different in role and service account. You can still create a role binding but the service account will get access to perform verbs on the resources only in the namespace as defined in the role and the role-binding need to be created in the same namespace as the role.

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

prometherion
prometherion

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

Related Questions