Comment append des utilisateurs à Kubernetes (kubectl)?

Pour un aperçu complet de l’authentification, consultez les documents officiels de Kubernetes sur l’ authentification et l’ autorisation.

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

Si vous êtes sur GKE / ACS, vous intégrez des structures respectives de gestion des identités et des access.

Si vous hébergez vous-même des kubernetes (ce qui est le cas lorsque vous utilisez kops), vous pouvez utiliser coreos / dex pour intégrer les fournisseurs d’identité LDAP / OAuth2.

pour Dex, il existe quelques clients cli open source comme suit:

• Nordstrom / Kubelogin
• pusher / k8s-auth-example

Si vous cherchez un moyen rapide et facile (pas le plus sûr et le plus facile à gérer à long terme) de commencer, vous pouvez abuser des serviceaccounts – avec 2 options pour les stratégies spécialisées pour contrôler l’access. (voir ci-dessous)

REMARQUE car le contrôle d’access basé sur les rôles 1.6 est fortement recommandé! cette réponse ne couvre pas la configuration RBAC

EDIT : Un excellent guide de Bitnami sur la configuration de l’utilisateur avec RBAC est également disponible.

Les étapes pour activer l’access au compte de service sont les suivantes (selon que votre configuration de cluster inclut des stratégies RBAC ou ABAC, ces comptes peuvent avoir des droits d’administrateur complets!):

EDIT : Voici un script bash pour automatiser la création de compte de service – voir les étapes ci-dessous

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

    kubectl create sa alice 

2. Obtenez le secret associé

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

3. Obtenir ca.crt de secret (en utilisant OSX base64 avec l’ -D pour décoder)

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

4. Obtenir un jeton de compte de service à partir de secret

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

5. Obtenir des informations à partir de votre configuration kubectl (contexte actuel, serveur ..)

    # 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 un nouvel ca.cert , suivez les étapes ci- ca.cert (en fonction des informations de ca.cert et $endpoint extraites ci-dessus:

   1. Installez kubectl

       brew install kubectl 

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

       kubectl config set-cluster cluster-staging \ --embed-certs=true \ --server=$endpoint \ --certificatee-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 intermédiaire

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

   5. Basculer le contexte actuel en alice-staging en alice-staging d’ alice-staging pour l’utilisateur

       kubectl config use-context alice-staging 

Pour contrôler l’access des utilisateurs avec les stratégies (en utilisant ABAC ), vous devez créer un fichier de policy (par exemple):

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

Fournir cette policy.json sur chaque nœud maître et append les --authorization-mode=ABAC --authorization-policy-file=/path/to/policy.json aux serveurs de l’API

Cela permettrait à Alice (via son compte de service) de lire uniquement les droits sur toutes les ressources dans l’espace de noms par défaut uniquement.

Vous dites :

Je dois permettre aux autres utilisateurs d’administrer également.

Mais selon la documentation

Les utilisateurs normaux sont supposés être gérés par un service externe et indépendant. Un administrateur dissortingbuant des clés privées, un magasin d’utilisateurs comme Keystone ou Google Accounts, même un fichier avec une liste de noms d’utilisateur et de mots de passe. À cet égard, Kubernetes n’a pas d’objects représentant des comptes d’utilisateur normaux. Les utilisateurs réguliers ne peuvent pas être ajoutés à un cluster via un appel API.

Vous devez utiliser un outil tiers pour cela.

== Modifier ==

Une solution pourrait être de créer manuellement une entrée utilisateur dans le fichier kubeconfig . De la documentation :

 # create kubeconfig entry $ kubectl config set-cluster $CLUSTER_NICK \ --server=https://1.1.1.1 \ --certificatee-authority=/path/to/apiserver/ca_file \ --embed-certs=true \ # Or if tls not needed, replace --certificatee-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-certificatee=/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 

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