Comment ajouter des utilisateurs à Kubernetes (kubectl) ?

Question

J'ai créé un cluster Kubernetes sur AWS avec kops et peut l'administrer avec succès via kubectl depuis ma machine locale.

Je peux voir la configuration actuelle avec kubectl config view ainsi que l'accès direct à l'état stocké à ~/.kube/config comme :

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://api.{CLUSTER_NAME}
  name: {CLUSTER_NAME}
contexts:
- context:
    cluster: {CLUSTER_NAME}
    user: {CLUSTER_NAME}
  name: {CLUSTER_NAME}
current-context: {CLUSTER_NAME}
kind: Config
preferences: {}
users:
- name: {CLUSTER_NAME}
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    password: REDACTED
    username: admin
- name: {CLUSTER_NAME}-basic-auth
  user:
    password: REDACTED
    username: admin

Je dois permettre à d'autres utilisateurs d'administrer également. Ce site guide de l'utilisateur décrit comment les définir sur la machine d'un autre utilisateur, mais ne décrit pas comment créer les informations d'identification de l'utilisateur dans le cluster lui-même. Comment faire ?

En outre, est-il sûr de simplement partager le cluster.certificate-authority-data ?

Answer 1

Pour un aperçu complet de l'authentification, consultez les documents officiels de Kubernetes sur Authentification y Autorisation

Pour les utilisateurs, vous utilisez idéalement un fournisseur d'identité pour Kubernetes (OpenID Connect).

Si vous êtes sur GKE / ACS, vous vous intégrez aux cadres respectifs de gestion des identités et des accès.

Si vous hébergez vous-même kubernetes (ce qui est le cas lorsque vous utilisez kops), vous pouvez utiliser coreos/dex pour intégrer les fournisseurs d'identité LDAP / OAuth2 - une bonne référence est ce document détaillé en 2 parties SSO pour Kubernetes article.

kops (1.10+) dispose désormais d'une fonction intégrée support d'authentification ce qui facilite l'intégration avec AWS IAM comme fournisseur d'identité si vous êtes sur AWS.

Pour Dex, il existe quelques clients cli à source ouverte, comme suit :

• Nordstrom/kubelogin
• poussoir/k8s-auth-exemple

Si vous cherchez un moyen rapide et facile (mais pas le plus sûr et le plus facile à gérer à long terme) de démarrer, vous pouvez abuser de serviceaccounts - avec 2 options de politiques spécialisées pour contrôler l'accès. (voir ci-dessous)

NOTE : depuis la version 1.6, le contrôle d'accès basé sur les rôles est fortement recommandé ! Cette réponse ne couvre pas la configuration du RBAC.

EDIT : Excellent, mais dépassé (2017-2018), guide de Bitnami sur . Configuration des utilisateurs avec RBAC est également disponible.

Les étapes pour activer l'accès aux comptes de service sont les suivantes (selon que la configuration de votre cluster inclut des politiques RBAC ou ABAC, ces comptes peuvent avoir des droits d'administration complets) :

EDIT : Voici un bash script pour automatiser la création d'un compte de service - voir les étapes suivantes

1. Créer un compte de service pour l'utilisateur Alice

   kubectl create sa alice

2. Obtenez le secret lié

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

3. Obtenez ca.crt à partir du secret (en utilisant OSX base64 con -D pour le décodage)

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

4. Obtenir le jeton de compte de service à partir du secret

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

5. Obtenir des informations de votre configuration kubectl (current-context, server..)

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

6. Sur une machine neuve, suivez les étapes suivantes (compte tenu de l'état d'avancement du projet). ca.cert y $endpoint l'information récupérée ci-dessus :

   1. Installer kubectl

       brew install kubectl

   2. Définir le cluster (exécuter dans le répertoire où ca.crt est stockée)

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

   3. Définir les informations d'identification de l'utilisateur

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

   4. Définir la combinaison de l'utilisateur alice avec le cluster staging

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

   5. Changer le contexte actuel en alice-staging pour l'utilisateur

       kubectl config use-context alice-staging

Pour contrôler l'accès des utilisateurs avec des politiques (en utilisant ABAC ), vous devez créer un policy (par exemple) :

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

Cette disposition policy.json sur chaque nœud maître et ajoutez --authorization-mode=ABAC --authorization-policy-file=/path/to/policy.json drapeaux aux serveurs API

Cela permettrait à Alice (par le biais de son compte de service) d'obtenir des droits de lecture seule sur toutes les ressources de l'espace de noms par défaut uniquement.

Answer 2

Vous dites :

Je dois permettre à d'autres utilisateurs d'administrer également.

Mais selon le documentation

Les utilisateurs normaux sont supposés être gérés par un service extérieur et indépendant. Un administrateur distribuant des clés privées, un magasin d'utilisateurs comme Keystone ou Google Accounts, voire un fichier contenant une liste de noms d'utilisateurs et de mots de passe. À cet égard, Kubernetes ne dispose pas d'objets représentant des comptes utilisateurs normaux. Les utilisateurs normaux ne peuvent pas être ajoutés à un cluster par le biais d'un appel API.

Vous devez utiliser un outil tiers pour cela.

\== Editer ==

Une solution pourrait consister à créer manuellement une entrée d'utilisateur dans le fichier fichier kubeconfig . De la documentation :

# create kubeconfig entry
$ kubectl config set-cluster $CLUSTER_NICK \
    --server=https://1.1.1.1 \
    --certificate-authority=/path/to/apiserver/ca_file \
    --embed-certs=true \
    # Or if tls not needed, replace --certificate-authority and --embed-certs with
    --insecure-skip-tls-verify=true \
    --kubeconfig=/path/to/standalone/.kube/config

# create user entry
$ kubectl config set-credentials $USER_NICK \
    # bearer token credentials, generated on kube master
    --token=$token \
    # use either username|password or token, not both
    --username=$username \
    --password=$password \
    --client-certificate=/path/to/crt_file \
    --client-key=/path/to/key_file \
    --embed-certs=true \
    --kubeconfig=/path/to/standalone/.kube/config

# create context entry
$ kubectl config set-context $CONTEXT_NAME \
    --cluster=$CLUSTER_NICK \
    --user=$USER_NICK \
    --kubeconfig=/path/to/standalone/.kube/config

Answer 3

Le guide bitnami fonctionne pour moi, même si vous utilisez minikube. Le plus important est que votre cluster supporte RBAC. https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/