Как добавить пользователей в Kubernetes (kubectl)?

для полного обзора аутентификации обратитесь к официальным документам Kubernetes на проверка подлинности и авторизация

для пользователей в идеале используется поставщик удостоверений для Kubernetes (OpenID Connect).

если вы находитесь на GKE / ACS, вы интегрируетесь с соответствующими фреймворками управления идентификацией и доступом

если вы самостоятельно принимаете kubernetes (что имеет место, когда вы используете kops), вы можете использовать coreos / dex для интеграции с поставщиками удостоверений LDAP / OAuth2-хорошей ссылкой является эта подробная 2 часть SSO для Kubernetes статьи.

для Dex есть несколько клиентов cli с открытым исходным кодом следующим образом:

• Nordstrom / kubelogin
• толкатель / k8s-auth-пример

если вы ищете быстрый и простой (но не самый безопасный и простой в управлении в долгосрочной перспективе) способ начать работу, вы можете злоупотреблять serviceaccounts - С 2 вариантами специализированных политик для управления доступом. (см. ниже)

Примечание, так как 1.6 роли на основе контроля доступа настоятельно рекомендуется! этот ответ не охватывает настройку RBAC

редактировать: Большой справочник по Об о настройка пользователя с помощью RBAC также доступна.

шаги для включения доступа к учетной записи службы (в зависимости от конфигурации кластера включает политики RBAC или ABAC, эти учетные записи могут иметь полные права администратора!):

редактировать: вот сценарий bash для автоматизации создания учетной записи службы-см. ниже шаги

1. создать учетную запись службы для

   kubectl create sa alice
   

2. получить связанный секрет

   secret=$(kubectl get sa alice -o json | jq -r .secrets[].name)
   

3. Get ca.crt из secret (с помощью OSX base64 С -D флаг decode)

   kubectl get secret $secret -o json | jq -r '.data["ca.crt"]' | base64 -D > ca.crt
   

4. получить маркер учетной записи службы от secret

   user_token=$(kubectl get secret $secret -o json | jq -r '.data["token"]' | base64 -D)
   

5. получить информацию из конфигурации kubectl (текущий контекст, сервер..)

   # get current context
   c=`kubectl config current-context`
   
   # get cluster name of context
   name=`kubectl config get-contexts $c | awk '{print }' | tail -n 1`
   
   # get endpoint of current context 
   endpoint=`kubectl config view -o jsonpath="{.clusters[?(@.name == \"$name\")].cluster.server}"`
   

6. на новой машине выполните следующие действия (учитывая ca.cert и $endpoint информация, полученная выше:

   1. установить kubectl

      brew install kubectl
      

   2. установить кластер (запустить в каталоге где ca.crt хранится)

      kubectl config set-cluster cluster-staging \
        --embed-certs=true \
        --server=$endpoint \
        --certificate-authority=./ca.crt
      

   3. задать учетные данные пользователя

      kubectl config set-credentials alice-staging --token=$user_token
      

   4. определите комбинацию пользователя alice с промежуточным кластером

      kubectl config set-context alice-staging \
        --cluster=cluster-staging \
        --user=alice-staging \
        --namespace=alice
      

   5. переключить текущий контекст на alice-staging для

      kubectl config use-context alice-staging
      

управление доступом пользователей с помощью политик (используя ДКС), вам нужно создать policy (например):

{
  "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
  "kind": "Policy",
  "spec": {
    "user": "system:serviceaccount:default:alice",
    "namespace": "default",
    "resource": "*",
    "readonly": true
  }
}

положение это policy.json на каждом главном узле и добавить --authorization-mode=ABAC --authorization-policy-file=/path/to/policy.json флаги для серверов API

это позволит Алисе (через ее учетную запись службы) читать только права на все ресурсы только в пространстве имен по умолчанию.