Как можно ограничить учетную запись службы, чтобы она могла создавать, перечислять, удалять и т. д. только те объекты, которые имеют определенную метку в заданном пространстве имен?
Мы разработали иерархию сервисов (которые сопоставляются с пространствами имен Kubernetes) и компонентов (которые представлены меткой personaна различных объектах) и интегрировали ее с хранилищем таким образом, что секреты, к которым у вас есть доступ, относятся к паре сервис-компонент. Это помогает разделить вещи. Например, представьте себе команду, которая управляет кучей развертываний, и только некоторые из них обрабатывают данные PII. Мы можем использовать эту метку, чтобы выборочно предоставлять доступ к этим секретам.
# only approximatively k8s objects
---
kind: Deployment
metadata:
name: backend
namespace: banana
labels:
persona: backend
spec: ...
# pods in this deployment have access to banana§backend secrets via a vault sidecar
---
kind: Deployment
metadata:
name: frontend
labels:
persona: frontend
spec: ...
# pods in this deployment have access to banana§frontend secrets via a vault sidecar
Однако это означает, что мы не просто хотим создать учетную запись службы, которая может управлятьвсемодули в этом пространстве имен — если секрет этой учетной записи службы будет раскрыт, злоумышленник может использовать его для запуска модуля с вредоносным образом и доступом к персональным данным.
Поэтому я хотел бы иметь что-то вроде: (обратите внимание, что мои знания об учетных записях служб, ролях и привязках ролей крайне ограничены)
# even more approximatively so k8s objects
kind: Role
metadata:
name: deploy-frontend
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
selector:
labels:
persona: frontend
# even if compromised, this service account cannot access banana§backend secrets
Похоже на k8sмощьподдерживать что-то вроде этого, например, предоставляя список конкретных имен ресурсов (#), но в остальном k8s на данный момент этого не поддерживает? Или я что-то упускаю?
Является ли наша единственная альтернатива — настроить общекластерную учетную запись службы с широким доступом ко всему, а затем развернуть веб-службу, которая выполняет собственную процедуру аутентификации и авторизации до использования токена? Если так, как мы можем максимально ограничить область действия этой «учетной записи бога»?
решение1
Kubernetes не имеет возможности ограничитьсписокглагол по объекту. Если вы можете перечислить коллекцию, вы можете прочитать все объекты в этой коллекции.
Может быть, когда-нибудь это изменится, но сейчас Kubernetes работает именно так с точки зрения коллекций и доступа на чтение. Это включает доступ на чтение к Secrets…
Однако, если вы хотите ограничитьпишетк объектам, вы можете это сделать. Вы можете ограничить возможность записи в определенные именованные объекты, используя:
- внешний веб-хук для проверки допуска
- a (бета) ПроверкаПолитики Приема
- вебхук авторизации
или с использованием тщательно разработанных правил RBAC.
Что может помочь вам управлять доступом — этоконтроллер иерархических пространств имен, позволяя команде управлятьнаборпространств имен, каждое из которых имеет свои собственные ограничения. Если ваш кластер поддерживает ValidatingAdmissionPolicies, вы можете использовать их для дальнейшего делегирования доступа и ограничений на доступ к записи (хотя это довольно сложная тема).
Если вы хотите иметь один ServiceAccount, который может что-то делать, но делегировать управление этими вещами, вы можете создать ServiceAccount в каждом целевом пространстве имен с RoleBinding, а затем разрешить общему ServiceAccount олицетворять конкретные ServiceAccount. Опять же, это довольно сложная вещь для охвата, но это возможно.