Какое имя пользователя использует kubernetes kubelet при обращении в API kubernetes?

Question

Итак, я пытаюсь реализовать авторизацию ABAC в API kubernetes со следующими аргументами в файле манифеста kube-api.

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

И следующее содержание в файле 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 }} 

Однако, kubelets, похоже, не может подключаться к серверам api. Я прочитал, что имя пользователя берется из поля CN в -subject в сертификате, используемом для аутентификации соединения, see here. В этом случае это fqdn шланга, я тоже пробовал, что не повезло.

Любые идеи, что я делаю неправильно?

Приветствия заранее

Edit:

Я использую Kubernetes версии 1.2.2, как kubectl и hyperkube докер изображения.

Answer 1

Выяснил ответ, документируя здесь, для кого-то другого, имеющего ту же проблему с ABAC.

kubelet пользователь определить в конфигурации рабочего, который в моем случае является YAML файл, который я хранить здесь - /etc/kubernetes/worker-kubeconfig.yaml, содержание которого приведен ниже:

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 

Таким образом, пользователь это соединение с есть kubelet.

В моем случае я создал свои сертификаты с CN = $ {MINION_FQDN}, и поскольку это не соответствовало «kubelet», тогда политики ABAC не выполнялись. Я регенерировать свои certifcates со следующими аргументами и теперь узлы аутентификации успешно :)

# 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 

важной часть которого заключается в следующем:

-subj "/CN=kubelet" 

Надеется, что это помогает кому-то еще.