С какой ролью и связыванием ролей связан kubectl? - PullRequest
Новая
       4

С какой ролью и связыванием ролей связан kubectl?

0 голосов
/ 11 апреля 2020

Я пытаюсь понять, как kubectl получает разрешения на запуск команд. Я понимаю, что все взаимодействия с кластерами kubernetes go через kube-apiserver. Поэтому, когда мы запускаем команду kubectl, скажем, kubectl get pods с главного узла, запрос будет go через kube-apiserver.

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

Извинения, если это нелепый вопрос.

Ответы [ 3 ]

2 голосов
/ 11 апреля 2020

Kubectl не связан с ролью или привязкой роли. Kubectl использует файл с именем kubeconfig. Этот файл имеет либо клиентский сертификат, либо токен-носитель JWT.

Если клиентский сертификат представляется и проверяется сервером API, общее имя субъекта используется в качестве имени пользователя для запроса.

Если используется токен-носитель JWT, то все данные, необходимые для идентификации пользователя, находятся в самом токене.

Так происходит аутентификация пользователя в kubernetes.

Пользователь авторизация определяется правилами управления доступом на основе ролей (RBA C) в форме роли и привязки роли.

2 голосов
/ 12 апреля 2020

Этот ответ является расширением других и помогает вам с помощью сценариев, когда используются клиентские сертификаты :

Получить пользователя и группу из текущего контекста:

Если вы используете клиентские сертификаты, ваш ~/.kube/config файл содержит client-certificate-data для пользователя текущего контекста. Эти данные представляют собой сертификат в кодировке base64, который может отображаться в текстовом виде с помощью openssel. Интересная информация по вашему вопросу находится в разделе Subject.

Этот скрипт напечатает строку Subject сертификата клиента: 

$ kubectl config view --raw -o json \
    | jq ".users[] | select(.name==\"$(kubectl config current-context)\")" \
    | jq -r '.user["client-certificate-data"]' \
    | base64 -d | openssl x509 -text | grep "Subject:"

Вывод на мой Ma c при запуске kubernetes через Docker для Ma c:

Subject: O=system:masters, CN=docker-for-desktop

O является организацией и представляет группу в Куберне.

CN является общим названием и интерпретируется как user by kubernetes.

Найдите соответствующий clusterrole и clusterrolebinding:

Теперь вы знаете, какого пользователя и группу вы используете с kubectl в данный момент. Чтобы выяснить, какую (кластерную) ролевую привязку вы используете, вам нужно найти указанную группу / пользователя: 

$ group="system:masters"
$ kubectl get clusterrolebindings -o json \
    | jq ".items[] | select(.subjects[].name==\"$group\")"

{
  "apiVersion": "rbac.authorization.k8s.io/v1",
  "kind": "ClusterRoleBinding",
  "metadata": {
    "annotations": {
      "rbac.authorization.kubernetes.io/autoupdate": "true"
    },
    "creationTimestamp": "2020-03-31T14:12:13Z",
    "labels": {
      "kubernetes.io/bootstrapping": "rbac-defaults"
    },
    "name": "cluster-admin",
    "resourceVersion": "95",
    "selfLink": "/apis/rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin",
    "uid": "878fa48b-cf30-42e0-8e3c-0f27834dfeed"
  },
  "roleRef": {
    "apiGroup": "rbac.authorization.k8s.io",
    "kind": "ClusterRole",
    "name": "cluster-admin"
  },
  "subjects": [
    {
      "apiGroup": "rbac.authorization.k8s.io",
      "kind": "Group",
      "name": "system:masters"
    }
  ]
}

В выводе видно, что эта группа связана с ClusterRole cluster-admin. Вы можете более подробно рассмотреть эту роль кластера, чтобы увидеть подробности разрешений: 

$ kubectl get clusterrole cluster-admin -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2020-03-31T14:12:12Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "42"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/cluster-admin
  uid: 9201f311-4d07-46c3-af36-2bca9ede098f
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
- nonResourceURLs:
  - '*'
  verbs:
  - '*'
1 голос
/ 11 апреля 2020

Вы можете использовать kubectl config view, чтобы увидеть, какой контекст активен сейчас. Вы увидите что-то вроде этого: 

contexts:
- context:
    cluster: my-cluster
    namespace: stage
    user: alice
  name: stage-ctx
current-context: stage-ctx

Это означает, что каждая команда переходит в stage пространство имен (если пространство имен не указано в команде) из my-cluster и аутентифицируется как пользователь alice там.

Следующая вещь происходит на стороне сервера. Вероятно, есть роль, которая позволяет кому-то делать и выводить список модулей. давайте назовем это edit-stage-role: 

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: stage
  name: edit-stage-role
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["pods"]
  verbs: ["get", "list"]

И есть также привязка, которая в основном назначает эту роль определенным субъектам, таким как группы или пользователи: 

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edit-stage-rb
  namespace: stage
roleRef:
  kind: Role
  name: edit-stage-role
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
- kind: User
  name: bob
  apiGroup: rbac.authorization.k8s.io

В этом примере она связывает Роль bob и alice. После того как запрос аутентифицирован и k8s знает, что вы являетесь пользователем alice, он пытается авторизовать запрос, оценивая ваши разрешения, которые хранятся в одной из ролей, связанных с alice.

С высокого уровня это выглядит нравится. Возможно, может быть несколько ролей или ClusterRoles, ClusterRB и другие параметры, но общая концепция выглядит одинаково.

И вы, как администратор, можете выдавать себя за конкретного пользователя в определенном пространстве имен, чтобы увидеть, работает ли набор ролей и привязок должным образом. Используйте эту команду: 

$ kubectl auth can-i get pods --namespace=stage --as alice
yes

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

Это только краткое объяснение. Вы можете прочитать больше на https://kubernetes.io/docs/reference/access-authn-authz/rbac/

...