Учетная запись службы по умолчанию для пространства имен Kubernetes

Если не указано, модули запускаются под учетной записью службы по умолчанию.

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

Среда: Kubernetes 1.12 с RBAC

Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...
15
0
24 430
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий
  1. Учетная запись службы по умолчанию автоматически создается для каждого пространства имен.

kubectl get serviceaccount

NAME SECRETS AGE

default 1 1d

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

  2. Модуль может использовать только одну учетную запись службы из одного и того же пространства имен.

  3. Учетная запись службы назначается модулю путем указания имени учетной записи в манифесте модуля. Если вы не назначите его явно, модуль будет использовать учетную запись службы по умолчанию.

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

  5. По умолчанию учетная запись службы по умолчанию в пространстве имен не имеет разрешений, кроме разрешений неаутентифицированного пользователя.

  6. Поэтому модули по умолчанию не могут даже просматривать состояние кластера. Вы должны предоставить им соответствующие разрешения для этого.

kubectl exec -it test -n foo sh / # curl localhost:8001/api/v1/namespaces/foo/services { "kind": "Status",
"apiVersion": "v1", "metadata": {

}, "status": "Failure", "message": "services is forbidden: User "system:serviceaccount:foo:default" cannot list resource "services" in API group "" in the namespace "foo"", "reason": "Forbidden", "details": { "kind": "services" }, "code": 403

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

но при наличии правильной роли и привязки ролей, как показано ниже

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: foo-role
  namespace: foo
rules:
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - get
  - list

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: null
  name: test-foo
  namespace: foo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: foo-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: foo

теперь я могу перечислить услуги по восстановлению

kubectl exec -it test -n foo sh
/ # curl localhost:8001/api/v1/namespaces/foo/services
{
  "kind": "ServiceList",
  "apiVersion": "v1",
  "metadata": {
    "selfLink": "/api/v1/namespaces/bar/services",
    "resourceVersion": "457324"
  },
  "items": []
  1. Предоставляя всем вашим сервисным аккаунтам, clusteradmin ClusterRole - это плохая идея. Лучше всего дать всем только те разрешения, которые им необходимы для выполнения своей работы, и ни единого разрешения больше.

  2. Рекомендуется создать отдельный сервисный аккаунт для каждого модуля. а затем свяжите его с индивидуальной ролью или ClusterRole через RoleBinding.

  3. Если одному из ваших модулей нужно только читать модули, а другому также необходимо их изменить, создайте две разные учетные записи служб и заставьте эти модули использовать их, указав свойство serviceaccountName в поле стручок спец.

Вы можете обратиться к приведенной ниже ссылке для более подробного объяснения.

Пример учетной записи службы с ролями

Вы можете проверить kubectl explain serviceaccount.automountServiceAccountToken и отредактировать учетную запись службы

kubectl изменить serviceaccount по умолчанию -o yaml

apiVersion: v1
automountServiceAccountToken: false
kind: ServiceAccount
metadata:
  creationTimestamp: 2018-10-14T08:26:37Z
  name: default
  namespace: default
  resourceVersion: "459688"
  selfLink: /api/v1/namespaces/default/serviceaccounts/default
  uid: de71e624-cf8a-11e8-abce-0642c77524e8
secrets:
- name: default-token-q66j4

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

kubectl exec tp -it bash
root@tp:/# cd /var/run/secrets/kubernetes.io/serviceaccount
bash: cd: /var/run/secrets/kubernetes.io/serviceaccount: No such file or directory

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

Ijaz Ahmad Khan 25.10.2018 23:44

Для учетной записи службы по умолчанию нельзя использовать глаголы, как я объяснил в примере выше. Вам необходимо связать учетную запись службы с ролью или кластерной ролью, как описано в пункте № 9. Вы можете установить флажок «kubectl объяснять serviceaccount.automountServiceAccountToken», это позволяет вам указывать логические значения. установка значения false не приведет к монтированию токена учетной записи службы. Каждый модуль поставляется с учетной записью службы без доступа, это сделано для безопасности.

Shashank Pai 26.10.2018 09:23

kubectl edit serviceaccount default -o yaml apiVersion: v1 automountServiceAccountToken: false kind: ServiceAccount metadata: creationTimestamp: 2018-10-14T08: 26: 37Z name: default namespace: default resourceVersion: "459688" selfLink: / api / v1 / namespaces / default / serviceaccounts / default uid: de71e624-cf8a-11e8-abce-0642c77524e8 секреты: - name: default-token-q66j4

Shashank Pai 26.10.2018 09:33

> «По умолчанию учетная запись службы по умолчанию в пространстве имен не имеет разрешений, кроме разрешений неаутентифицированного пользователя». ------ Спасибо !!! Я действительно хочу, чтобы это утверждение было в официальной документации Kubernetes. Я целый день читал документацию по продуктам Kubernetes, Istio, блоги людей и т. д., Пытаясь выследить этот факт. Никто из них не сказал бы просто то, что вы только что сказали, или не дал бы последовательность команд в стиле учебника (как ваша), чтобы я научился экспериментировать сам. Ваш ответ великолепен - он не оставляет никаких сомнений в том, какова функциональность по умолчанию.

Vincent Yin 05.07.2021 01:33

Приложение / развертывание можно запустить с учетной записью службы, отличной от default, указав ее в поле serviceAccountName конфигурации развертывания.

То, что я обслуживаю учетную запись или любой другой пользователь, может делать, определяется ролями, которые ей предоставлены (привязаны) - см. RoleBindings или clusterRoleBindings; глаголы соответствуют apiGroups роли и resources определениям rules.

Учетная запись службы default по умолчанию не имеет никаких ролей. Можно назначить роль учетной записи службы default, как описано в # 2 здесь.

Согласно это, «... В версии 1.6+ вы можете отказаться от автоматического монтирования учетных данных API для учетной записи службы, установив automountServiceAccountToken: false в учетной записи службы».

HTH

Каковы варианты использования учетной записи службы по умолчанию, можем и должны ли мы использовать ее в качестве учетной записи службы для создания и управления развертываниями k8s в пространстве имен? , например, мы не будем использовать реальные учетные записи пользователей для создания вещей в кластере, потому что пользователи приходят и уходят в команде

Ijaz Ahmad Khan 26.10.2018 14:11

Другие вопросы по теме