Разрешения по умолчанию для учетной записи службы Kubernetes

Экспериментирую со служебными аккаунтами. Я считаю, что следующее должно вызвать ошибку доступа (но это не так):

apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-sa

---

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  serviceAccountName: test-sa
  containers:
  - image: alpine
    name: test-container
    command: [sh]
    args:
    - -ec
    - |
      apk add curl;
      KUBE_NAMESPACE="$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)";
      curl \
        --cacert "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" \
        -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
        "https://kubernetes.default.svc/api/v1/namespaces/$KUBE_NAMESPACE/services";
      while true; do sleep 1; done;

kubectl apply -f test.yml
kubectl logs test-pod

Я вижу успешный список служб, но я ожидал бы ошибки разрешений, потому что я никогда не создавал никаких RoleBinding или ClusterRoleBinding для test-sa.

Я изо всех сил пытаюсь найти способы перечислить разрешения, доступные для конкретной SA, но согласно Kubernetes check serviceaccount permissions, это должно быть возможно с:

kubectl auth can-i list services --as=system:serviceaccount:default:test-sa
> yes

Хотя я скептически отношусь к тому, действительно ли эта команда работает, потому что я могу заменить test-sa любой тарабарщиной, и она все равно говорит «да».

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

kubectl get clusterroles system:discovery -o yaml
> [...]
> rules:
> - nonResourceURLs:
>   - /api
>   - /api/*
> [...]
>   verbs:
>   - get

Это означало бы, что все учетные записи служб имеют get разрешения на все конечные точки API, хотя бит nonResourceURLs подразумевает, что это не будет применяться к API для ресурсов, таких как службы, даже если эти API находятся по этому пути… (???)

Если я полностью удалю заголовок Authorization, я увижу ошибку доступа, как и ожидалось. Но я не понимаю, почему он может получать данные с помощью этой пустой учетной записи службы. В чем мое недоразумение и как правильно ограничить разрешения?


kubernetes docker-desktop permissions kubernetes-security
person Dave    schedule 14.07.2020    source источник
comment
Вы можете поделиться выводом kubectl get role,rolebinding -n default и kubectl get clusterrole,clusterrolebinding   -  person Arghya Sadhu    schedule 14.07.2020
comment
Первая команда @ArghyaSadhu возвращает В пространстве имен по умолчанию ресурсы не найдены. Второй возвращает большой список, включающий clusterrole.rbac.authorization.k8s.io/admin, clusterrole.rbac.authorization.k8s.io/system:controller:service-controller и clusterrolebinding.rbac.authorization.k8s.io/system:controller:service-controller среди многих других. Что-нибудь особенное из этого вывода, о котором вы хотите узнать?   -  person Dave    schedule 14.07.2020
comment
Вы случайно создали привязку кластера для привязки этой учетной записи службы к cluster-admin роли кластера?   -  person Arghya Sadhu    schedule 14.07.2020
comment
Если это поможет: это локальное тестовое развертывание кубернетов с использованием встроенной в Docker опции Включить Kubernetes. Я считаю, что у него нет настраиваемой конфигурации. И что бы то ни было, запуск kubectl cluster-info dump | grep authorization-mode показывает, что режимы управления доступом Node,RBAC   -  person Dave    schedule 14.07.2020
comment
@ArghyaSadhu Я очень в этом сомневаюсь; это не похоже на то, что могло бы случиться случайно! Как я могу точно сказать? Возможно, стоит отметить, что учетная запись службы test-sa является недавно созданной - я могу изменить ее имя и снова запустить apply и увидеть тот же эффект, поэтому я не думаю, что это связано с каким-либо глупым состоянием на этом ресурсе.   -  person Dave    schedule 14.07.2020
comment
Я просто попробовал тот же yaml в своем кластере kubeadm и получил ошибку 403, которая ожидается   -  person Arghya Sadhu    schedule 14.07.2020
comment
Я попрошу коллег попробовать его в различных средах. Может быть, дело в том, как docker desktop связывает кубернеты?   -  person Dave    schedule 14.07.2020
comment
@ArghyaSadhu, мой коллега помог мне найти clusterrolebinding docker-for-desktop-binding, который добавляет cluster-admin к system:serviceaccounts (?!). Так что, похоже, это действительно настольный докер.   -  person Dave    schedule 14.07.2020
comment
Повышенный github.com/docker/for-mac/issues/4774 - превращается это уже было признано ошибкой в ​​рабочем столе докеров для Mac, но они исправили ее неправильно.   -  person Dave    schedule 14.07.2020

Ответы (3)


arrow_upward
2
arrow_downward

Оказывается, это ошибка в поддержке Kubernetes Docker Desktop для Mac.

Он автоматически добавляет ClusterRoleBinding дающий cluster-admin ко всем сервисным аккаунтам (!). Он только намеревается передать это служебным учетным записям в пространстве имен kube-system.

Первоначально он был поднят в docker / for-mac # 3694, но исправлен неправильно. Я поднял новую проблему docker / for-mac № 4774 (исходный выпуск заблокирован из-за возраста).

Быстрое исправление в ожидании исправления ошибки - запустить:

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: docker-for-desktop-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts:kube-system
EOF

Я не знаю, может ли это вызвать проблемы с будущими обновлениями Docker Desktop, но на данный момент он выполняет свою работу.

С этим исправлением приведенный выше код правильно выдает ошибку 403 и потребует следующего, чтобы явно предоставить доступ к ресурсу служб:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: service-reader
rules:
- apiGroups: [""]
  resources: [services]
  verbs: [get, list]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-sa-service-reader-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: service-reader
subjects:
- kind: ServiceAccount
  name: test-sa

Полезной командой для исследования является kubectl auth can-i --list --as system:serviceaccount, которая показывает, что несанкционированные разрешения применялись ко всем учетным записям служб:

Resources                       Non-Resource URLs   Resource Names   Verbs
*.*                             []                  []               [*]
                                [*]                 []               [*]
[...]
person Dave    schedule 14.07.2020

arrow_upward
1
arrow_downward

Такая же ошибка существует в Docker-Desktop для Windows.

Он автоматически добавляет ClusterRoleBinding, дающий администратора кластера для всех учетных записей служб (!). Он намеревается предоставить это только сервисным учетным записям внутри пространства имен kube-system.

person Mazziruso    schedule 30.06.2021

arrow_upward
0
arrow_downward

Это связано с тем, что в Docker Desktop по умолчанию привязка кластера docker-for-desktop-binding дает cluster-admin роль всем созданным учетным записям служб.

Дополнительные сведения см. здесь

person Arghya Sadhu    schedule 14.07.2020