Jak dodawać użytkowników do Kubernetes (kubectl)?

Stworzyłem klaster Kubernetes na AWS za pomocą kops i mogę z powodzeniem administrować nim za pośrednictwem kubectl z mojej lokalnej maszyny.

Mogę przeglądać bieżącą konfigurację za pomocą kubectl config view, a także uzyskać bezpośredni dostęp do zapisanego stanu w ~/.kube/config, na przykład:

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

Muszę umożliwić innym użytkownikom również administrowanie. Ten podręcznik użytkownika opisuje, jak zdefiniować je na innym komputerze użytkownika, ale nie opisuje, jak faktycznie utworzyć poświadczenia użytkownika w samym klastrze. Jak ty to robisz?

Również, czy jest to bezpieczne, aby po prostu podzielić się cluster.certificate-authority-data?

Author: Ortomala Lokni, 2017-02-11

3 answers

Aby uzyskać pełny przegląd uwierzytelniania, zapoznaj się z oficjalnymi dokumentami Kubernetes dotyczącymi uwierzytelniania i autoryzacji

Dla użytkowników najlepiej jest użyć dostawcy tożsamości dla Kubernetes (OpenID Connect).

Jeśli korzystasz z GKE / ACS, integrujesz się z odpowiednimi frameworkami zarządzania tożsamością i dostępem]}

Jeśli sam hostujesz kubernetes( tak jest w przypadku kops), możesz użyć coreos/dex do integracji z LDAP / OAuth2 dostawcy tożsamości-dobrym punktem odniesienia jest ten szczegółowy 2 część SSO Dla artykułu Kubernetes .

Dla Dex istnieje kilka klientów open source cli w następujący sposób:

Jeśli szukasz szybkiego i łatwego (Nie najbezpieczniejszego i łatwego do zarządzania w dłuższej perspektywie) sposobu na rozpoczęcie pracy, możesz nadużywać serviceaccounts - z 2 Opcjami specjalnych zasad kontroli dostępu. (patrz poniżej)

Uwaga Od 1.6 Kontrola dostępu oparta na rolach jest zdecydowanie zalecane! ta odpowiedź nie obejmuje konfiguracji RBAC

EDIT : świetny przewodnik by Bitnami on User setup with RBAC jest również dostępny.

Kroki, aby włączyć dostęp do konta usługi są (w zależności od tego, czy konfiguracja klastra zawiera zasady RBAC lub ABAC, konta te mogą mieć pełne prawa administratora!):

Edytuj: oto skrypt bash do automatyzacji Tworzenie konta usługi-patrz poniżej kroki

  1. Utwórz konto serwisu dla użytkownika Alice

    kubectl create sa alice
    
  2. Get related secret

    secret=$(kubectl get sa alice -o json | jq -r .secrets[].name)
    
  3. Get ca.crt from secret (using OSX base64 with -D flag for decode)

    kubectl get secret $secret -o json | jq -r '.data["ca.crt"]' | base64 -D > ca.crt
    
  4. Pobierz token konta usługowego z secret

    user_token=$(kubectl get secret $secret -o json | jq -r '.data["token"]' | base64 -D)
    
  5. Uzyskaj informacje z konfiguracji 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. Na świeżej maszynie, wykonaj następujące kroki (biorąc pod uwagę ca.cert i $endpoint informacje pobrane powyżej:

    1. Install kubectl

      brew install kubectl
      
    2. Set cluster (run in directory where ca.crt is stored)

      kubectl config set-cluster cluster-staging \
        --embed-certs=true \
        --server=$endpoint \
        --certificate-authority=./ca.crt
      
    3. Ustaw poświadczenia użytkownika

      kubectl config set-credentials alice-staging --token=$user_token
      
    4. Zdefiniuj kombinację użytkownika alice z klastrem staging

      kubectl config set-context alice-staging \
        --cluster=cluster-staging \
        --user=alice-staging \
        --namespace=alice
      
    5. Przełącz current-context na alice-staging dla użytkownika

      kubectl config use-context alice-staging
      

Aby kontrolować użytkownika dostęp z polisami (za pomocą ABAC ), musisz utworzyć policy plik (na przykład):

{
  "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
  "kind": "Policy",
  "spec": {
    "user": "system:serviceaccount:default:alice",
    "namespace": "default",
    "resource": "*",
    "readonly": true
  }
}
W tym celu należy dodać znaczniki dla każdego węzła nadrzędnego i dodać znaczniki dla każdego węzła nadrzędnego.]}

To umożliwi Alice (poprzez jej konto usługowe) prawa tylko do odczytu wszystkich zasobów w domyślnej przestrzeni nazw.

 67
Author: Vincent De Smet,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-04-10 08:40:16

Mówisz:

Muszę umożliwić innym użytkownikom również administrowanie.

Ale zgodnie z dokumentacją

Zakłada się, że zwykli użytkownicy są zarządzani przez zewnętrzną, niezależną usługę. Administrator dystrybuujący klucze prywatne, sklep użytkownika, taki jak Keystone lub konta Google, a nawet Plik z listą nazw użytkowników i haseł. W związku z tym Kubernetes nie ma obiektów, które reprezentują zwykłe konta użytkowników. Zwykli użytkownicy nie mogą być dodawani do klaster poprzez wywołanie API.

Musisz użyć do tego narzędzia innej firmy.

== Edit = =

Jednym z rozwiązań może być ręczne utworzenie wpisu użytkownika w pliku kubeconfig . Z dokumentacji :

# 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
 0
Author: Ortomala Lokni,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-02-11 09:52:44

Przewodnik Bitnami działa dla mnie, nawet jeśli używasz minikube. Najważniejsze jest to, że klaster obsługuje RBAC. https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/

 0
Author: Gabriel Wu,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-08-14 07:50:13