Kubernetes: ClusterRole, созданные в кластере, не видны во время проверок rba c - PullRequest
Новая
       59

Kubernetes: ClusterRole, созданные в кластере, не видны во время проверок rba c

0 голосов
/ 02 апреля 2020

У меня есть проблема в моем кластере Kubernetes, которая неожиданно появилась через две недели go. Созданные ClusterRoles не видны, когда разрешены значения RBA C для заданного ServiceAccount. Вот минимальный набор для воспроизведения проблемы.

Создайте соответствующие ClusterRole, ClusterRoleBinding и ServiceAccount в пространстве имен default, чтобы иметь права на просмотр конечных точек с этим SA. 

# test.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-sa
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: test-cr
rules:
- apiGroups: [""]
  resources: ["endpoints"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: test-crb
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: test-cr
subjects:
- kind: ServiceAccount
  name: test-sa
  namespace: default

$ kubectl apply -f test.yaml
serviceaccount/test-sa created
clusterrole.rbac.authorization.k8s.io/test-cr created
clusterrolebinding.rbac.authorization.k8s.io/test-crb created

Все объекты, в частности ClusterRole, видны при прямом запросе. 

$ kubectl get serviceaccount test-sa
NAME      SECRETS   AGE
test-sa   1         57s

$ kubectl get clusterrolebinding test-crb
NAME       AGE
test-crb   115s

$ kubectl get clusterrole test-cr
NAME      AGE
test-cr   2m19s

Однако, когда я пытаюсь разрешить действующие права для этого ServiceAccount, я получаю сообщение об ошибке: 

$ kubectl auth can-i get endpoints --as=system:serviceaccount:default:test-sa
no - RBAC: clusterrole.rbac.authorization.k8s.io "test-cr" not found

Правила RBA C, созданные до поломки, работают правильно. Например, здесь для ServiceAccount моего etcd-оператора, который я развернул с Helm несколько месяцев: go: 

$ kubectl auth can-i get endpoints --as=system:serviceaccount:etcd:etcd-etcd-operator-etcd-operator
yes

Версия Kubernetes в этом кластере - 1.17.0-0.

В последнее время я также вижу очень медленные развертывания новых модулей, которые могут начать развертываться после 5 минут после того, как они были созданы StatefulSet или Deployment, если это может помочь.

Do у вас есть понимание того, что происходит, или даже что я могу с этим поделать? Обратите внимание, что мой кластер Kubernetes управляется, поэтому я не имею никакого контроля над базовой системой, у меня просто есть привилегии cluster-admin в качестве клиента. Но все равно было бы очень полезно, если бы я мог дать какое-либо указание администраторам.

Заранее спасибо!

1 Ответ

0 голосов
/ 23 апреля 2020

Большое спасибо за ваши ответы!

Оказалось, что у нас никогда не будет окончательного мира о том, что происходит. Поставщик кластера просто перезапустил kube-apiserver, и это устранило проблему.

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

Чтобы дать немного больше данных для будущего читателя, ошибка произошла в кластере Kubernetes, управляемом OVH, и их специфика заключается в том, чтобы запускать саму плоскость управления в виде модулей, развернутых в главном кластере Kubernetes на их стороне.

...