"kubectl exec" führt zu "Fehler: konnte nicht aktualisieren-Verbindung: Unerlaubte"

Versuchte ich kubectl exec auf eine k8s 1.6.4 RBAC-aktiviert cluster-und der zurückgegebene Fehler war: error: unable to upgrade connection: Unauthorized. docker exec auf den gleichen container gelingt. Ansonsten kubectl arbeitet. kubectl Tunneln durch eine SSH-Verbindung aber ich glaube nicht, dass dies das Problem ist.

kubelet authn ist aktiviert, aber nicht authz. Die docs sagen, dass authz ist AlwaysAllow standardmäßig, also ich habe es auf diese Weise.

Habe ich das Gefühl, dass es ähnlich ist dieses Problem. Aber die Fehlermeldung ist ein bisschen anders.

Vielen Dank im Voraus!

Ausführliche Protokolle für die kubectl exec Befehl:

I0614 16:50:11.003677   64104 round_trippers.go:398] curl -k -v -XPOST  -H "X-Stream-Protocol-Version: v4.channel.k8s.io" -H "X-Stream-Protocol-Version: v3.channel.k8s.io" -H "X-Stream-Protocol-Version: v2.channel.k8s.io" -H "X-Stream-Protocol-Version: channel.k8s.io" https://localhost:6443/api/v1/namespaces/monitoring/pods/alertmanager-main-0/exec?command=%2Fbin%2Fls&container=alertmanager&container=alertmanager&stderr=true&stdout=true
I0614 16:50:11.003705   64104 round_trippers.go:398] curl -k -v -XPOST  -H "X-Stream-Protocol-Version: v4.channel.k8s.io" -H "X-Stream-Protocol-Version: v3.channel.k8s.io" -H "X-Stream-Protocol-Version: v2.channel.k8s.io" -H "X-Stream-Protocol-Version: channel.k8s.io" -H "User-Agent: kubectl/v1.6.4 (darwin/amd64) kubernetes/d6f4332" https://localhost:6443/api/v1/namespaces/monitoring/pods/alertmanager-main-0/exec?command=%2Fbin%2Fls&container=alertmanager&container=alertmanager&stderr=true&stdout=true
I0614 16:50:11.169474   64104 round_trippers.go:417] POST https://localhost:6443/api/v1/namespaces/monitoring/pods/alertmanager-main-0/exec?command=%2Fbin%2Fls&container=alertmanager&container=alertmanager&stderr=true&stdout=true 401 Unauthorized in 165 milliseconds
I0614 16:50:11.169493   64104 round_trippers.go:423] Response Headers:
I0614 16:50:11.169497   64104 round_trippers.go:426]     Date: Wed, 14 Jun 2017 08:50:11 GMT
I0614 16:50:11.169500   64104 round_trippers.go:426]     Content-Length: 12
I0614 16:50:11.169502   64104 round_trippers.go:426]     Content-Type: text/plain; charset=utf-8
I0614 16:50:11.169506   64104 round_trippers.go:417] POST https://localhost:6443/api/v1/namespaces/monitoring/pods/alertmanager-main-0/exec?command=%2Fbin%2Fls&container=alertmanager&container=alertmanager&stderr=true&stdout=true 401 Unauthorized in 165 milliseconds
I0614 16:50:11.169509   64104 round_trippers.go:423] Response Headers:
I0614 16:50:11.169512   64104 round_trippers.go:426]     Date: Wed, 14 Jun 2017 08:50:11 GMT
I0614 16:50:11.169545   64104 round_trippers.go:426]     Content-Length: 12
I0614 16:50:11.169548   64104 round_trippers.go:426]     Content-Type: text/plain; charset=utf-8
F0614 16:50:11.169635   64104 helpers.go:119] error: unable to upgrade connection: Unauthorized
  • können Sie geben einige details auf diesem "kubectl Tunnel' wie sind Sie mit der Erstellung der tunnel mit ssh.
  • Ich nach vorne localhost:6443 an den worker-Knoten wie dieser ssh -L 6443:localhost:6443 worker1.kube. Dann habe ich die config kubectl zu verbinden localhost:6443.
InformationsquelleAutor Eugene Chow | 2017-06-14
  1. 5

    Dies ist ein RTFM moment... Die Lösung war im Grunde Folgen alle Schritte, die auf auf dieser Seite für authn, authz, oder beides.

    Hatte ich weggelassen --kubelet-client-certificate und --kubelet-client-key die zu dem Fehler geführt haben. Ohne diese flags kube-apiserver nicht authentifizieren mit kubelet wenn Sie eine kubectl exec.

    Meine ursprüngliche Versuch, Sie zu konfigurieren authn war durch das Lesen der Dokumentation für die kubelet daemon (ie. nicht das oben). Damit das Grab Unterlassung.

    • Wo fügen Sie diese Parameter?
    • Es konfiguriert ist, in kube-apiserver's manifest. Die offizielle Dokumentation wird genau erklären, wie es funktioniert.
    InformationsquelleAutor Eugene Chow
  2. 1

    In meinem Fall (beim lernen Kubernetes Die Harte Weise, ich hatte zum konfigurieren von RBAC-Berechtigungen zu ermöglichen, die Kubernetes-API-Server für den Zugriff auf die Kubelet-API auf jedem worker node. Ich habe ClusterRole und ClusterRoleBinding Zugriff auf die Kubelet API 

    ---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-apiserver-to-kubelet
rules:
  - apiGroups:
      - ""
    resources:
      - nodes/proxy
      - nodes/stats
      - nodes/log
      - nodes/spec
      - nodes/metrics
    verbs:
      - "*"

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: system:kube-apiserver
  namespace: ""
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kube-apiserver-to-kubelet
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: kube-apiserver

    Referenzen:

    InformationsquelleAutor vikas027
Schreibe einen Kommentar