Если не указано, модули запускаются под учетной записью службы по умолчанию.
Среда: Kubernetes 1.12 с RBAC
kubectl get serviceaccount
NAME SECRETS AGE
default 1 1d
При необходимости сервисные аккаунты могут быть добавлены. Каждый модуль связан ровно с одной учетной записью службы, но несколько модулей могут использовать одну и ту же учетную запись службы.
Модуль может использовать только одну учетную запись службы из одного и того же пространства имен.
Учетная запись службы назначается модулю путем указания имени учетной записи в манифесте модуля. Если вы не назначите его явно, модуль будет использовать учетную запись службы по умолчанию.
Разрешения по умолчанию для учетной записи службы не позволяют перечислить или изменить любые ресурсы. Учетной записи службы по умолчанию не разрешено просматривать состояние кластера, не говоря уже о том, чтобы изменять его каким-либо образом.
По умолчанию учетная запись службы по умолчанию в пространстве имен не имеет разрешений, кроме разрешений неаутентифицированного пользователя.
Поэтому модули по умолчанию не могут даже просматривать состояние кластера. Вы должны предоставить им соответствующие разрешения для этого.
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": []
Предоставляя всем вашим сервисным аккаунтам, clusteradmin
ClusterRole - это
плохая идея. Лучше всего дать всем только те разрешения, которые им необходимы для выполнения своей работы, и ни единого разрешения больше.
Рекомендуется создать отдельный сервисный аккаунт для каждого модуля. а затем свяжите его с индивидуальной ролью или ClusterRole через RoleBinding.
Если одному из ваших модулей нужно только читать модули, а другому также необходимо их изменить, создайте две разные учетные записи служб и заставьте эти модули использовать их, указав свойство 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
Для учетной записи службы по умолчанию нельзя использовать глаголы, как я объяснил в примере выше. Вам необходимо связать учетную запись службы с ролью или кластерной ролью, как описано в пункте № 9. Вы можете установить флажок «kubectl объяснять serviceaccount.automountServiceAccountToken», это позволяет вам указывать логические значения. установка значения false не приведет к монтированию токена учетной записи службы. Каждый модуль поставляется с учетной записью службы без доступа, это сделано для безопасности.
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
> «По умолчанию учетная запись службы по умолчанию в пространстве имен не имеет разрешений, кроме разрешений неаутентифицированного пользователя». ------ Спасибо !!! Я действительно хочу, чтобы это утверждение было в официальной документации Kubernetes. Я целый день читал документацию по продуктам Kubernetes, Istio, блоги людей и т. д., Пытаясь выследить этот факт. Никто из них не сказал бы просто то, что вы только что сказали, или не дал бы последовательность команд в стиле учебника (как ваша), чтобы я научился экспериментировать сам. Ваш ответ великолепен - он не оставляет никаких сомнений в том, какова функциональность по умолчанию.
Приложение / развертывание можно запустить с учетной записью службы, отличной от default
, указав ее в поле serviceAccountName
конфигурации развертывания.
То, что я обслуживаю учетную запись или любой другой пользователь, может делать, определяется ролями, которые ей предоставлены (привязаны) - см. RoleBindings или clusterRoleBindings; глаголы соответствуют apiGroups
роли и resources
определениям rules
.
Учетная запись службы default
по умолчанию не имеет никаких ролей. Можно назначить роль учетной записи службы default
, как описано в # 2 здесь.
Согласно это, «... В версии 1.6+ вы можете отказаться от автоматического монтирования учетных данных API для учетной записи службы, установив automountServiceAccountToken: false
в учетной записи службы».
HTH
Каковы варианты использования учетной записи службы по умолчанию, можем и должны ли мы использовать ее в качестве учетной записи службы для создания и управления развертываниями k8s в пространстве имен? , например, мы не будем использовать реальные учетные записи пользователей для создания вещей в кластере, потому что пользователи приходят и уходят в команде
Спасибо, вопрос все еще остается, как я могу перечислить, какие глаголы разрешены для учетной записи службы по умолчанию в пространстве имен, и как мы можем отключить монтирование токена учетной записи службы по умолчанию в модуль по умолчанию, на уровне имен или кластера, и является ли это обязательным для запуска модуля со служебной учетной записью по умолчанию