Welchen Benutzernamen verwendet der kubernetes kubelet bei der Kontaktaufnahme mit der kubernetes API?

Question

Also habe ich versucht, ABAC-Autorisierung in der Kubernetes-API mit den folgenden Argumenten in meiner kube-api-Manifest-Datei zu implementieren.

- --authorization-mode=ABAC 
    - --authorization-policy-file=/etc/kubernetes/auth/abac-rules.json 

Und der folgende Inhalt in der Datei abac-rulse.json.

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"*",   "nonResourcePath": "*", "readonly": true}} 
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"admin",  "namespace": "*",    "resource": "*",   "apiGroup": "*"     }} 
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"scheduler", "apiGroup": "*", "namespace": "*", "resource": "*", "readonly": false}} 
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"kubelet", "apiGroup": "*", "namespace": "*", "resource": "*", "readonly": false }} 

Jedoch können die kubelets anscheinend keine Verbindung zu den api-Servern herstellen. Ich habe gelesen, dass der Benutzername aus dem CN-Feld des -subject in dem Zertifikat zur Authentifizierung der Verbindung, see here genommen wird. In diesem Fall ist das der FQDN des Schlauches, ich habe das auch ohne Glück versucht.

Irgendwelche Ideen, was ich falsch mache?

Prost im Voraus

Edit:

Ich verwende Kubernetes Version 1.2.2, die beide kubectl und hyperkube Docker Bild.

Answer 1

Die Antwort gefunden, hier für jemand anderen mit dem gleichen Problem mit ABAC dokumentiert.

Der kubelet Benutzer ist in der Arbeiter-Konfiguration definieren, die in meinem Fall eine YAML-Datei ist, die ich hier speichern - /etc/kubernetes/worker-kubeconfig.yaml, deren Inhalt ist unten dargestellt:

apiVersion: v1 
kind: Config 
clusters: 
- name: default 
    cluster: 
    server: https://10.96.17.34:8443 
    certificate-authority: /etc/kubernetes/ssl/ca.pem 
users: 
- name: kubelet 
    user: 
    client-certificate: /etc/kubernetes/ssl/worker.pem 
    client-key: /etc/kubernetes/ssl/worker-key.pem 
contexts: 
- context: 
    cluster: default 
    user: kubelet 
    name: kubelet-context 
current-context: kubelet-context 

so dass der Benutzer es mit ist Verbindungs ist kubelet.

In meinem Fall hatte ich meine Zertifikate mit dem CN = $ {MINION_FQDN}, und da dies nicht "kubelet" übereinstimmen, dann wurden die ABAC-Richtlinien nicht erfüllt. Ich regenerierte meinen certifcates mit den folgenden Argumenten und jetzt die Knoten authentifizieren erfolgreich :)

# Create worker key 
openssl genrsa -out $OUT/${WORKER_HOSTNAME}/worker-key.pem 2048 
#Creating Worker CSR... 
WORKER_FQDN=${WORKER_FQDN} WORKER_IP=${WORKER_IP} openssl req -new -key $OUT/${WORKER_HOSTNAME}/worker-key.pem -out $OUT/${WORKER_HOSTNAME}/worker.csr -subj "/CN=kubelet" -config $SSL_CONFIG 
# Creating Worker Cert 
WORKER_FQDN=${WORKER_FQDN} WORKER_IP=${WORKER_IP} openssl x509 -req -in $OUT/${WORKER_HOSTNAME}/worker.csr -CA $CA/ca.pem -CAkey $CA/ca-key.pem -CAcreateserial -out $OUT/${WORKER_HOSTNAME}/worker.pem -days 365 -extensions v3_req -extfile $SSL_CONFIG 

Der wichtige Teil davon ist dies:

-subj "/CN=kubelet" 

Hope this jemand anderes hilft.