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

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

2 голосов
/ 14 июля 2020

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

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 s или ClusterRoleBinding s для test-sa.

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

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

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

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

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

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

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

Ответы [ 2 ]

1 голос
/ 14 июля 2020

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

Он автоматически добавляет 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 обновлениями рабочего стола, но на данный момент он выполняет свою работу.

С этим исправлением приведенный выше код правильно дает ошибка 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
*.*                             []                  []               [*]
                                [*]                 []               [*]
[...]
0 голосов
/ 14 июля 2020

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

Подробнее см. Проблему здесь

...