Пространство имен для пользователя или роль в Kubernetes

Question

Я знаю, что роль используется для предоставления разрешения пользователям или учетной записи службы выполнять операции в указанном c пространстве имен.
Типичное определение роли может быть таким:

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: mynamespace

Мои вопросы:
1. Применяется ли область имен к учетной записи пользователя / службы или роли?
2. что если пространство имен в учетной записи службы и роли отличаются

определение привязки роли для ссылки

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

Answer 1

1. Пространство имен применяется ко всем трем ролям, учетной записи службы и привязке роли.
2. Не имеет значения, отличается ли пространство имен в роли и учетной записи службы. Вы все еще можете создать привязку роли, но учетная запись службы получит доступ к выполнению глаголов для ресурсов только в пространстве имен, как определено в роли, и привязка роли должна быть создана в том же пространстве имен, что и роль.

---

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

А затем проверил разрешение учетной записи службы

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

Как мы видим, учетная запись службы получила разрешение получать, просматривать, перечислять модули в пространстве имен, но не имеет того же разрешения в пространстве имен по умолчанию, хотя учетная запись службы находится в пространстве имен по умолчанию.

Теперь, если я удаляю привязку роли и создаю ее в пространстве имен по умолчанию вместо пространства имен .

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

---

Как видно, разрешение больше не применяется.

Answer 2

Сервисная учетная запись как Роль Ресурсы ограничены пространством имен: это позволяет ограничить определенные c действия для данного аутентифицированного пользователя (в этом примере Сервисная учетная запись ) в соответствии с ролью .

Поскольку речь идет о RBA C, вам необходим третий ресурс для привязки, определяющий c Роль ресурсов для данной Сервисной учетной записи : здесь появляется Ролевая привязка , еще один ресурс в области имен, который сопоставляет эти политики с заданным набором пользователей.

Поскольку все эти три компонента являются строго пространствами имен, все они должны находиться в одном и том же пространстве имен: в противном случае ссылка на учетную запись службы не будет работать.