web-dev-qa-db-fra.com

Comment ajouter des utilisateurs à Kubernetes (kubectl)?

J'ai créé un cluster Kubernetes sur AWS avec kops et je peux l'administrer avec succès via kubectl à partir de mon ordinateur local.

Je peux voir la configuration actuelle avec kubectl config view ainsi qu'accéder directement à l'état stocké sur ~/.kube/config, tel que:

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

J'ai besoin de permettre à d'autres utilisateurs d'administrer également. Ce guide de l'utilisateur explique comment les définir sur un autre ordinateur mais ne décrit pas comment créer réellement les informations d'identification de l'utilisateur au sein du cluster lui-même. Comment est-ce que tu fais ça?

Aussi, est-il prudent de simplement partager le cluster.certificate-authority-data?

kuberneteskubectlkops
60
peterl

Pour un aperçu complet de l'authentification, reportez-vous à la documentation officielle de Kubernetes sur Authentification et Autorisation

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

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

Si vous auto-hébergez 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 - une bonne référence est cette 2 partie détaillée SSO pour Kubernetes article.

kops (1.10+) a désormais intégré support d'authentification , ce qui facilite l'intégration avec AWS IAM en tant que fournisseur d'identité si vous êtes sur AWS.

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

Si vous recherchez un moyen rapide et simple (pas très sûr et facile à gérer à long terme), vous pouvez abuser de serviceaccounts - avec 2 options de stratégies spécialisées pour contrôler l'accès. (voir ci-dessous)

NOTE depuis 1.6 Le contrôle d'accès basé sur les rôles est fortement recommandé! cette réponse ne couvre pas la configuration RBAC

EDIT: le meilleur guide de Bitnami sur configuration utilisateur avec RBAC est également disponible.

Les étapes permettant d'activer l'accès au compte de service sont les suivantes (selon que la configuration de votre cluster inclut des stratégies RBAC ou ABAC, ces comptes peuvent disposer de tous les droits d'administrateur!):

EDIT: Voici un script bash pour automatiser la création d'un 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 lié

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

  3. Obtenir ca.crt du secret (en utilisant OSX base64 avec l'indicateur -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 du secret

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

  5. Obtenir des informations de votre config 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 ces étapes (étant donné les informations 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 \
  --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 d'utilisateur alice avec le cluster de transfert

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

    5. Basculez current-context sur alice-staging pour l'utilisateur

      kubectl config use-context alice-staging

Pour contrôler l'accès des utilisateurs avec des stratégies (à l'aide de ABAC ), vous devez créer un fichier policy (par exemple):

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

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

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

83
Vincent De Smet

Vous dites :

J'ai besoin de permettre à d'autres utilisateurs d'administrer également.

Mais selon le documentation

Les utilisateurs normaux sont supposés être gérés par un service externe indépendant. Un administrateur distribuant des clés privées, un magasin d'utilisateurs comme Keystone ou des comptes Google, voire un fichier contenant une liste de noms d'utilisateur et de mots de passe. À cet égard, Kubernetes n'a pas d'objets qui représentent des comptes d'utilisateur normaux. Les utilisateurs ordinaires ne peuvent pas être ajoutés à un cluster via un appel d'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 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
1
Ortomala Lokni

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

0
Gabriel Wu