K8s-pki: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
 
(не показано 87 промежуточных версий этого же участника)
Строка 1: Строка 1:
  +
[[Категория:SSL]]
  +
[[Категория:PKI]]
  +
[[Категория:k8s]]
 
=Заметка о PKI/CA в kubernetes=
  
=Заметка о PKI/CA в kubernetes=
 
Эта заметка появилась для того что бы раз и навсегда прояснить какие CA и сертификаты используются в control-plane, для чего они используются и почему именно такие.
  
Эта заметка появилась для того что бы раз и навсегда прояснить какие CA и сертификаты используются в control-plane, для чего они используются и почему именно такие.
   
 
<BR>
  
<BR>
−
Предполагается что у читающего есть базовое понимание TLS/SSL/CA/PKI/OpenSSL
 +
Предполагается что у читающего есть базовое понимание '''TLS/SSL/CA/PKI/OpenSSL'''
   
 
<BR>
  
<BR>
 
Julia Evans - мой герой! https://jvns.ca/blog/2017/08/05/how-kubernetes-certificates-work/
  
Julia Evans - мой герой! https://jvns.ca/blog/2017/08/05/how-kubernetes-certificates-work/
−
<BR>
  
−
Далее - частичный перевод а частично мои собственные мысли.
  
   
  +
<big>'''Структура заметки следующая'''</big>
  +
* Первая часть - пример настройки PKI вручную для всех сервисов K8S
  +
* Вторая часть - заметки которые были написаны в процессе понимания (хронологически она первая но читать ее не обязательно и написано местами сумбурно)
  +
  +
  +
<big>'''Используется внешний уже настроенный Vault'''</big>
  +
* Токен не секретный только в тестовых инсталляциях - в общем случае использовать один рутовый токен для всего плохая идея
   
 
=Почему возникла эта заметка=
  
=Почему возникла эта заметка=
Строка 28: Строка 36:
 
etcd also implements mutual TLS to authenticate clients and peers.
  
etcd also implements mutual TLS to authenticate clients and peers.
 
<BR>
  
<BR>
−
При этом я не нашел никакой информации о том каким свойствами должны обладать сертификаты, должны ли они быть подписаны одним CA?
+
При этом я не нашел никакой информации о том каким свойствами должны обладать сертификаты, должны ли они быть подписаны одним CA?
   
  +
=Практика=
  +
Насколько я могу судить можно использовать следующие CA (которые не обязаны но могут быть одним и тем же CA)
  +
  +
==СA0 Доступ к etcd==
  +
По сути эта настройка никак не связана с k8s - просто нужны клиентские сертификаты подписанные СА etcd
  +
<BR>
  +
===kube-apiserver===
  +
<PRE>
  +
/usr/local/bin/kube-apiserver \
  +
...
  +
--etcd-certfile=/etc/k8s/kube-apiserver/etcd/etcd.k8s.home.pem \
  +
--etcd-keyfile=/etc/k8s/kube-apiserver/etcd/etcd.k8s.home.key \
  +
--etcd-servers=${ETCD_SERVER} \
  +
...
  +
</PRE>
  +
  +
==СA1 Для авторизации клиентов у kube-apiserver==
  +
  +
===Подготовка PKI===
  +
<PRE>
  +
mkdir kube-apiserver/client-auth
  +
</PRE>
  +
<BR>
  +
====Подготовка переменных окружения для PKI====
  +
<BR>
  +
{{#spoiler:show=Переменные окружения|
  +
<PRE>
  +
export VAULT_TOKEN="s.Yb1J2VamFyYoav3VVE2YQQ88"
  +
export VAULT_ADDR="http://vault.home:8200"
  +
export PKI_PATH="pki_intermediate_ca_for_k8s_kube_apiserver_client_auth"
  +
export KUBE_APISERVER_DOMAIN_NAME="kube-apiserver.az1.k8s.home"
  +
</PRE>
  +
}}
  +
<BR>
  +
====Создание промежуточного CA====
  +
PKI_PATH - просто человеко-читаемый путь он может быть строго говоря любым
  +
<BR>
  +
{{#spoiler:show=Промежуточный CA|
  +
<PRE>
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
vault secrets enable \
  +
-path=${PKI_PATH} \
  +
-description="PKI Intermediate CA for K8S kube-apiserver client-auth" \
  +
-max-lease-ttl="175200h" \
  +
pki
  +
</PRE>
  +
}}
  +
<BR>
  +
====Создание запроса на сертификат для промежуточного CA====
  +
<BR>
  +
{{#spoiler:show=CSR|
  +
<PRE>
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
vault write \
  +
-format=json \
  +
${PKI_PATH}/intermediate/generate/internal \
  +
common_name="Intermediate CA for Kubernetes Cluster" \
  +
country="UA" \
  +
province="Kharkov" \
  +
locality="Kharkov" \
  +
organization="Home Network Lab" \
  +
ou="IT" \
  +
cn="Kubernetes" \
  +
street_address="Lui Pastera st. 322 app. 131" \
  +
postal_code="61172" \
  +
ttl="175200h" > ${PKI_PATH}.csr.json
  +
</PRE>
  +
}}
  +
<BR>
  +
====Извлечение CSR из ответа и сохранение в удобном формате====
  +
<BR>
  +
{{#spoiler:show=Json-to-CSR format|
  +
<PRE>
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
cat ${PKI_PATH}.csr.json \
  +
| jq -r '.data.csr' > ${PKI_PATH}.csr
  +
  +
openssl \
  +
req \
  +
-text \
  +
-noout \
  +
-verify \
  +
-in ${PKI_PATH}.csr
  +
</PRE>
  +
}}
  +
<BR>
  +
====Подписать промежуточный сертификат CA основным CA====
  +
(подробнее в статье про Vault PKI https://noname.com.ua/mediawiki/index.php/Vault_PKI)
  +
<BR>
  +
{{#spoiler:show=Подписать промежуточный CA|
  +
<PRE>
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
  +
vault write \
  +
-format=json \
  +
pki_root_ca/root/sign-intermediate \
  +
csr=@${PKI_PATH}.csr \
  +
format=pem_bundle \
  +
country="UA" \
  +
province="Kharkov" \
  +
locality="Kharkov" \
  +
organization="Home Network Lab" \
  +
ou="IT" \
  +
cn="Kubernetes" \
  +
street_address="Lui Pastera st. 322 app. 131" \
  +
postal_code="61172" \
  +
ttl="175200h" \
  +
>${PKI_PATH}.pem.json
  +
</PRE>
  +
}}
  +
<BR>
  +
==== Извлечение сертификата из ответа и сохранение в удобном формате (PEM) ====
  +
<big>'''Это СА для клиентов и именно его использует kube-apiserver для проверки клиентов (если не используется прокси?)'''</big>
  +
<BR>
  +
{{#spoiler:show=Json-to-PEM|
  +
<PRE>
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
  +
cat ${PKI_PATH}.pem.json \
  +
| jq -r '.data.certificate' > ${PKI_PATH}.pem
  +
  +
openssl \
  +
x509 \
  +
-text \
  +
-noout \
  +
-in ${PKI_PATH}.pem
  +
  +
  +
</PRE>
  +
}}
  +
<BR>
  +
====Загрузка подписанного сертификата в Vault====
  +
<BR>
  +
{{#spoiler:show=Load_PEM|
  +
<PRE>
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
  +
vault \
  +
write \
  +
${PKI_PATH}/intermediate/set-signed \
  +
certificate=@${PKI_PATH}.pem
  +
</PRE>
  +
}}
  +
<BR>
  +
  +
====Прописать URL====
  +
<BR>
  +
{{#spoiler:show=Add urls|
  +
<PRE>
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
vault \
  +
write \
  +
${PKI_PATH}/config/urls \
  +
issuing_certificates="http://vault.home:8200/v1/${PKI_PATH}/ca" \
  +
crl_distribution_points="http://vault.home:8200/v1/${PKI_PATH}/crl"
  +
</PRE>
  +
}}
  +
<BR>
  +
  +
====Создать роль для создания клиентских сертификатов====
  +
<BR>
  +
{{#spoiler:show=create_role|
  +
<PRE>
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
vault \
  +
write \
  +
${PKI_PATH}/roles/certeficates-clients-only-${KUBE_APISERVER_DOMAIN_NAME} \
  +
country="UA" \
  +
province="Kharkov" \
  +
locality="Kharkov" \
  +
organization="Home Network Lab" \
  +
ou="system" \
  +
street_address="Lui Pastera st. 322 app. 131" \
  +
postal_code="61172" \
  +
max_ttl="87600h" \
  +
key_bits="2048" \
  +
key_type="rsa" \
  +
allow_any_name=true \
  +
client_flag=true \
  +
server_flag=false \
  +
enforce_hostnames=false \
  +
key_usage="DigitalSignature,KeyEncipherment" \
  +
ext_key_usage="ClientAuth" \
  +
require_cn=true
  +
  +
</PRE>
  +
}}
  +
<BR>
  +
  +
====Выпустить сертификат для system:kube-controller-manager====
  +
<BR>
  +
{{#spoiler:show=issue_cert_for_CN="system:kube-controller-manager|
  +
<PRE>
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
set -o pipefail
  +
  +
source ./env.sh
  +
  +
CN="system:kube-controller-manager"
  +
  +
vault \
  +
write \
  +
-format=json \
  +
${PKI_PATH}/issue/certeficates-clients-only-${KUBE_APISERVER_DOMAIN_NAME} \
  +
common_name="${CN}" \
  +
ttl="43800h" > ${CN}.crt.json
  +
  +
cat \
  +
${CN}.crt.json \
  +
| jq -r '.data.private_key' > ${CN}.key
  +
  +
cat \
  +
${CN}.crt.json \
  +
| jq -r '.data.certificate' > ${CN}.pem
  +
  +
cat \
  +
${CN}.crt.json \
  +
| jq -r '.data.ca_chain[]' >> ${CN}.pem
  +
</PRE>
  +
}}
  +
<BR>
  +
  +
===СA1 где используются сертификаты===
  +
====kube-apiserver====
  +
CA используется для проверки клиентских сертификатов
  +
* Параметр <B>--client-ca-file</B>
  +
* Путь к сертификату в моей течтоыой инсталляции <B>/etc/k8s/kube-apiserver/client-auth/ca/pki_intermediate_ca_for_k8s_kube_apiserver_client_auth.pem</B>
  +
* ключ к этому сертификату хранится в Vault и достать его нельзя - все клиентские сертификаты выписываются с помощью Vault
  +
<PRE>
  +
/usr/local/bin/kube-apiserver \
  +
...
  +
--client-ca-file=/etc/k8s/kube-apiserver/client-auth/ca/pki_intermediate_ca_for_k8s_kube_apiserver_client_auth.pem \
  +
...
  +
</PRE>
  +
====kube-control-manager====
  +
Сертификат подписанный этим СА
  +
<PRE>
  +
/usr/local/bin/kube-controller-manager \
  +
...
  +
--kubeconfig=/etc/k8s/kube-controller-manager/kube-controller-manager.kubeconfig \
  +
...
  +
</PRE>
  +
В файле <B>/etc/k8s/kube-controller-manager/kube-controller-manager.kubeconfig</B> (кроме других параметров) - путь к сертификатам
  +
<BR>
  +
* client-certificate: /etc/k8s/kube-controller-manager/kube-apiserver/system:kube-controller-manager.pem
  +
* client-key: /etc/k8s/kube-controller-manager/kube-apiserver/system:kube-controller-manager.key
  +
В этом сертификате CN это username по сути
  +
  +
<PRE>
  +
apiVersion: v1
  +
clusters:
  +
- cluster:
  +
certificate-authority: /etc/k8s/shared/CA/pki_intermediate_ca_for_k8s_kube_apiserver_tls.pem
  +
server: https://kube-apiserver.az1.k8s.home:6443
  +
name: kubernetes-the-hard-way
  +
contexts:
  +
- context:
  +
cluster: kubernetes-the-hard-way
  +
user: system:kube-controller-manager
  +
name: default
  +
current-context: default
  +
kind: Config
  +
preferences: {}
  +
users:
  +
- name: system:kube-controller-manager
  +
user:
  +
client-certificate: /etc/k8s/kube-controller-manager/kube-apiserver/system:kube-controller-manager.pem
  +
client-key: /etc/k8s/kube-controller-manager/kube-apiserver/system:kube-controller-manager.key
  +
</PRE>
  +
  +
===1===
  +
<BR>
  +
{{#spoiler:show=1|
  +
<PRE>
  +
  +
</PRE>
  +
}}
  +
<BR>
  +
  +
==СA2 TLS для kube-apiserver==
  +
===Подготовка PKI===
  +
Не останавливаясь подробно на шагах - просто пример конфигурации.
  +
  +
<BR>
  +
{{#spoiler:show=Настройка|
  +
<PRE>
  +
env.sh
  +
  +
export VAULT_TOKEN="s.Yb1J2VamFyYoav3VVE2YQQ88"
  +
export VAULT_ADDR="http://vault.home:8200"
  +
export PKI_PATH="pki_intermediate_ca_for_k8s_kube_apiserver_tls"
  +
export KUBE_APISERVER_DOMAIN_NAME="kube-apiserver.az1.k8s.home"root@pi-node-1
  +
</PRE>
  +
  +
  +
<PRE>
  +
010-vault-intermediate-ca.sh
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
vault secrets enable \
  +
-path=${PKI_PATH} \
  +
-description="PKI Intermediate CA for K8S" \
  +
-max-lease-ttl="175200h" \
  +
pki
  +
</PRE>
  +
  +
  +
<PRE>
  +
020-create-intermediate-ca-crt-request.sh
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
vault write \
  +
-format=json \
  +
${PKI_PATH}/intermediate/generate/internal \
  +
common_name="Intermediate CA for Kubernetes Cluster" \
  +
country="UA" \
  +
province="Kharkov" \
  +
locality="Kharkov" \
  +
organization="Home Network Lab" \
  +
ou="IT" \
  +
cn="Kubernetes" \
  +
street_address="Lui Pastera st. 322 app. 131" \
  +
postal_code="61172" \
  +
ttl="175200h" > ${PKI_PATH}.csr.json
  +
  +
exit
  +
</PRE>
  +
  +
  +
<PRE>
  +
025-get-intermediate-cert-request-from-json.sh
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
  +
cat ${PKI_PATH}.csr.json \
  +
| jq -r '.data.csr' > ${PKI_PATH}.csr
  +
  +
openssl \
  +
req \
  +
-text \
  +
-noout \
  +
-verify \
  +
-in ${PKI_PATH}.csr
  +
  +
</PRE>
  +
  +
  +
<PRE>
  +
030_sign_intermediate_cert.sh
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
  +
vault write \
  +
-format=json \
  +
pki_root_ca/root/sign-intermediate \
  +
csr=@${PKI_PATH}.csr \
  +
format=pem_bundle \
  +
country="UA" \
  +
province="Kharkov" \
  +
locality="Kharkov" \
  +
organization="Home Network Lab" \
  +
ou="IT" \
  +
cn="Kubernetes" \
  +
street_address="Lui Pastera st. 322 app. 131" \
  +
postal_code="61172" \
  +
ttl="175200h" \
  +
>${PKI_PATH}.pem.json
  +
  +
</PRE>
  +
  +
  +
<PRE>
  +
035-get-intermediate-cert-from-json.sh
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
  +
cat ${PKI_PATH}.pem.json \
  +
| jq -r '.data.certificate' > ${PKI_PATH}.pem
  +
  +
openssl \
  +
x509 \
  +
-text \
  +
-noout \
  +
-in ${PKI_PATH}.pem
  +
  +
</PRE>
  +
  +
  +
<PRE>
  +
040_load_intermediatae_cert_to_vault.sh
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
  +
vault \
  +
write \
  +
${PKI_PATH}/intermediate/set-signed \
  +
certificate=@${PKI_PATH}.pem
  +
  +
  +
  +
</PRE>
  +
  +
  +
<PRE>
  +
050-configure-intermediate-ca-urls.sh
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
  +
vault \
  +
write \
  +
${PKI_PATH}/config/urls \
  +
issuing_certificates="http://vault.home:8200/v1/${PKI_PATH}/ca" \
  +
crl_distribution_points="http://vault.home:8200/v1/${PKI_PATH}/crl"
  +
  +
</PRE>
  +
  +
  +
<PRE>
  +
060-create-role-for-server-only-cert.sh
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
vault \
  +
write \
  +
${PKI_PATH}/roles/certeficates-server-only-${KUBE_APISERVER_DOMAIN_NAME} \
  +
country="UA" \
  +
province="Kharkov" \
  +
locality="Kharkov" \
  +
organization="Home Network Lab" \
  +
ou="IT" \
  +
cn="Kubernetes" \
  +
street_address="Lui Pastera st. 322 app. 131" \
  +
postal_code="61172" \
  +
allowed_domains="${KUBE_APISERVER_DOMAIN_NAME}" \
  +
allow_subdomains=false \
  +
max_ttl="87600h" \
  +
key_bits="2048" \
  +
key_type="rsa" \
  +
allow_any_name=false \
  +
allow_bare_domains=true \
  +
allow_glob_domain=false \
  +
allow_ip_sans=true \
  +
allow_localhost=false \
  +
client_flag=false \
  +
server_flag=true \
  +
enforce_hostnames=true \
  +
key_usage="DigitalSignature,KeyEncipherment" \
  +
ext_key_usage="ServerAuth" \
  +
require_cn=true
  +
  +
</PRE>
  +
  +
  +
<PRE>
  +
065-create-role-for-client-only-cert.sh
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
source ./env.sh
  +
  +
vault \
  +
write \
  +
${PKI_PATH}/roles/certeficates-clients-only-${KUBE_APISERVER_DOMAIN_NAME} \
  +
country="UA" \
  +
province="Kharkov" \
  +
locality="Kharkov" \
  +
organization="Home Network Lab" \
  +
ou="system" \
  +
street_address="Lui Pastera st. 322 app. 131" \
  +
postal_code="61172" \
  +
max_ttl="87600h" \
  +
key_bits="2048" \
  +
key_type="rsa" \
  +
allow_any_name=true \
  +
client_flag=true \
  +
server_flag=false \
  +
enforce_hostnames=false \
  +
key_usage="DigitalSignature,KeyEncipherment" \
  +
ext_key_usage="ClientAuth" \
  +
require_cn=true
  +
  +
</PRE>
  +
  +
  +
<PRE>
  +
500-issue-server-cert.sh
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
set -o pipefail
  +
  +
source ./env.sh
  +
  +
vault \
  +
write \
  +
-format=json \
  +
${PKI_PATH}//issue/certeficates-server-only-${KUBE_APISERVER_DOMAIN_NAME} \
  +
common_name="${KUBE_APISERVER_DOMAIN_NAME}" \
  +
ttl="43800h" > ${KUBE_APISERVER_DOMAIN_NAME}.crt.json
  +
  +
cat \
  +
${KUBE_APISERVER_DOMAIN_NAME}.crt.json \
  +
| jq -r '.data.private_key' > ${KUBE_APISERVER_DOMAIN_NAME}.key
  +
  +
cat \
  +
${KUBE_APISERVER_DOMAIN_NAME}.crt.json \
  +
| jq -r '.data.certificate' > ${KUBE_APISERVER_DOMAIN_NAME}.pem
  +
  +
cat \
  +
${KUBE_APISERVER_DOMAIN_NAME}.crt.json \
  +
| jq -r '.data.ca_chain[]' >> ${KUBE_APISERVER_DOMAIN_NAME}.pem
  +
  +
</PRE>
  +
  +
  +
<PRE>
  +
510-issue-client-cert.sh
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
set -o pipefail
  +
  +
source ./env.sh
  +
  +
CN="system:kube-controller-manager"
  +
  +
vault \
  +
write \
  +
-format=json \
  +
${PKI_PATH}/issue/certeficates-clients-only-${KUBE_APISERVER_DOMAIN_NAME} \
  +
common_name="${CN}" \
  +
ttl="43800h" > ${CN}.crt.json
  +
  +
cat \
  +
${CN}.crt.json \
  +
| jq -r '.data.private_key' > ${CN}.key
  +
  +
cat \
  +
${CN}.crt.json \
  +
| jq -r '.data.certificate' > ${CN}.pem
  +
  +
cat \
  +
${CN}.crt.json \
  +
| jq -r '.data.ca_chain[]' >> ${CN}.pem
  +
  +
</PRE>
  +
}}
  +
<BR>
  +
  +
===СA2 где используются сертификаты===
  +
====kube-apiserver====
  +
Это серверные сертификаты с CN=доменное имя API сервера нужны собственно для HTTPS
  +
<PRE>
  +
/usr/local/bin/kube-apiserver \
  +
...
  +
--tls-cert-file=/etc/k8s/kube-apiserver/tls/kube-apiserver.az1.k8s.home.pem \
  +
--tls-private-key-file=/etc/k8s/kube-apiserver/tls/kube-apiserver.az1.k8s.home.key \
  +
...
  +
</PRE>
  +
====kube-controller-manager====
  +
CA указан в клиентах что бы они могли проверить сертификат сервера
  +
<PRE>
  +
/usr/local/bin/kube-controller-manager \
  +
...
  +
--kubeconfig=/etc/k8s/kube-controller-manager/kube-controller-manager.kubeconfig \
  +
...
  +
</PRE>
  +
<PRE>
  +
apiVersion: v1
  +
clusters:
  +
- cluster:
  +
certificate-authority: /etc/k8s/shared/CA/pki_intermediate_ca_for_k8s_kube_apiserver_tls.pem
  +
server: https://kube-apiserver.az1.k8s.home:6443
  +
name: kubernetes-the-hard-way
  +
</PRE>
  +
  +
==CA3 TLS для kube-control-manager==
  +
===Подготовка PKI===
  +
Настройка полностью аналогична CA2 - но используется для создания серверных сертификатов kube-controller-manager
  +
  +
===СA3 где используются сертификаты===
  +
====kube-controller-manager====
  +
<PRE>
  +
/usr/local/bin/kube-controller-manager \
  +
--bind-address=0.0.0.0 \
  +
--tls-cert-file=/etc/k8s/kube-controller-manager/tls/kube-controller-manager.az1.k8s.home.pem \
  +
--tls-private-key-file=/etc/k8s/kube-controller-manager/tls/kube-controller-manager.az1.k8s.home.key \
  +
...
  +
</PRE>
  +
  +
==kube-apiserver==
  +
  +
==kube-controller-manager==
  +
  +
==kubelet==
  +
  +
* ИМЕН НОД ВАЖНЫ
  +
https://kubernetes.io/docs/reference/access-authn-authz/node/
  +
  +
=Разбор от Джулии с моими комментариями=
 
Вот что пишет по этому поводу Джулия (перевод мой):
  
Вот что пишет по этому поводу Джулия (перевод мой):
 
<PRE>
  
<PRE>
Строка 46: Строка 711:
 
У API сервера 16 (ШЕСТНАДЦАТЬ, КАРЛ) аргументов которые так или иначе относятся к шифрованию:
  
У API сервера 16 (ШЕСТНАДЦАТЬ, КАРЛ) аргументов которые так или иначе относятся к шифрованию:
 
<PRE>
  
<PRE>
  +
--cert-dir string The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/run/kubernetes")
−
--cert-dir string
  
  +
--client-ca-file string If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
−
</PRE>
  
  +
--etcd-certfile string SSL certification file used to secure etcd communication.
−
The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/run/kubernetes")
  
  +
--etcd-keyfile string SSL key file used to secure etcd communication.
−
<PRE>
  
−
--client-ca-file string If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
  
−
--etcd-certfile string SSL certification file used to secure etcd communication.
  
−
--etcd-keyfile string SSL key file used to secure etcd communication.
  
 
--etcd-cafile string SSL Certificate Authority file used to secure etcd communication.
  
--etcd-cafile string SSL Certificate Authority file used to secure etcd communication.
 
--kubelet-certificate-authority string Path to a cert file for the certificate authority.
  
--kubelet-certificate-authority string Path to a cert file for the certificate authority.
Строка 73: Строка 735:
 
Четыреждыблядская ярость. На этом месте я подумал что может ну его нахуй и не так уж сильно я хочу изучить Kubernetes.
  
Четыреждыблядская ярость. На этом месте я подумал что может ну его нахуй и не так уж сильно я хочу изучить Kubernetes.
   
  +
Еще информация к размышлению (да я тоже был очень удивлен!):
−
=The API server’s TLS certificate (and certificate authority)=
  
  +
<PRE>
−
* <B>--tls-cert-file</B> string
  
  +
One thing I found surprising about this is – almost everything else in the universe that uses TLS will look in /etc/ssl to find a list of certificate authorities the computer trusts by default. But Kubernetes doesn’t do that, instead it mandates “no, you have to say exactly which CA issued the API server’s TLS cert”.
  +
</PRE>
  +
Другими словами использовать добавленные в систему доверенные CA не получится.
   
  +
==Нужен ли единый CA для кластера (нет)==
−
File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and <B>--tls-cert-file</B> and <B>--tls-private-key-file</B> are not provided, a self-signed certificate and key are generated for the public address and saved to /var/run/kubernetes.
  
  +
Такой вопрос возник не только у меня:
−
* <B> --tls-private-key-file</B>string
 
  +
<PRE>Does a Kubernetes cluster have to have a single root certificate authority? (no)</PRE>
  +
Дальше мой вольный перевод:
   
  +
Если вы прочитали кучу мануалов про установку кластера, то в каждом из них есть шаг "Постройте свой СА" ("set up a certificate authority".</BR>
−
File containing the default x509 private key matching <B>--tls-cert-file.</B>
  
  +
Kelsey Hightower’s c его прекрасной, но недостаточно подробной инструкцией “kubernetes the hard way” делает это на втором шаге.
  +
<BR>инструкция гласит
  +
<PRE>
  +
Every Kubernetes cluster has a cluster root Certificate Authority (CA).
  +
The CA is generally used by cluster components to validate the API server’s certificate, by the API server to validate kubelet client certificates, etc.
  +
</PRE>
  +
В общих чертах это работает так
  +
  +
* Настройте свой центр выдачи сертефикатов (обычно предлагают скрипты cfssl)
  +
* Нагенерите сертификатов подписанных своим СА для разных частей кластера
  +
  +
Тут сразу же возникает вопрос - а что делать <B>если я не хочу городить новый PKI для каждого кластера</B>
  +
<BR>
  +
Фраза (“every Kubernetes cluster has a [single] cluster root Certificate Authority”) ошибочна полностью - можно как использовать один CA для нескольких кластеров так и несколько СА для одного кластера.
  +
  +
==kube-apiserver==
  +
===The API server’s TLS certificate (and certificate authority)===
  +
Параметры
  +
* <B>--tls-cert-file</B> string File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and <B>--tls-cert-file</B> and <B>--tls-private-key-file</B> are not provided, a self-signed certificate and key are generated for the public address and saved to /var/run/kubernetes.
  +
* <B> --tls-private-key-file</B>string File containing the default x509 private key matching <B>--tls-cert-file.</B>
  +
  +
Относительно простая часть - эти параметры отвечают за <B>серверный</B> сертификат и его ключ который будет на Endpoint. В общем случае неплохо сделать так что бы curl мог подключиться туда без проблем - т е добавить CА который подписал этот сертификат в доверенные (или сделать bundle с промежуточным CA).
  +
<BR>
  +
Так же важно что бы тут был <big>правильный</big>домен</sup>(и IP в SAN)
  +
<BR>
  +
<BR>
  +
  +
После устновки TLS для API требуется подготовить '''kubeconfig''' для других компонетов (таких как kubelet and kubectl) которым требуется коммуникация с API.
  +
<BR>
  +
  +
'''kubeconfig''' выглядит примерно так
  +
<PRE>
  +
current-context: my-context
  +
apiVersion: v1
  +
clusters:
  +
- cluster:
  +
certificate-authority: /path/to/my/ca.crt # Путь к CA которым был подписан сертификат для API указанный в параметре --tls-cert-file kube-apiserver
  +
server: https://horse.org:4443 # Доменное имя должно быьть указано в сертификате, который указан в параметре --tls-cert-file kube-apiserver
  +
name: my-cluster
  +
kind: Config
  +
users:
  +
- name: green-user
  +
user:
  +
client-certificate: path/to/my/client/cert # РАССМОТРЕНО НИЖЕ
  +
client-key: path/to/my/client/key # РАССМОТРЕНО НИЖЕ
  +
</PRE>
  +
Напоминаю что системные СА игнорируются и нужно ЯВНО указать путь к СА которым подписан сертификат
  +
<BR>
  +
Вопросы пока без ответа
  +
* current-context
  +
* name: my-cluster
  +
  +
  +
  +
<BR>
  +
Файл kubeconfig передается компонентам как парамерт --kubeconfig /path/to/kubeconfig.yaml
  +
<BR>
  +
  +
Итого - первый СА это СА для TLS на API (при этом сам корневой сертификат используется только для проверки подлиности сервера а его ключ нигде не присутствует.
  +
(назовем этот СА - СА1)
  +
Этот СА может использоваться ТОЛЬКО для указанных целей и не совпадать ни с одним другим СА кластера.
  +
  +
===The API server client certificate authority (+ certificates)===
  +
<PRE>
  +
--client-ca-file string
  +
If set, any request presenting a client certificate signed by one of the
  +
authorities in the client-ca-file is authenticated with an identity
  +
corresponding to the CommonName of the client certificate.
  +
</PRE>
  +
Один из возможных способов для компонентов Kubernetes '''авторизоваться''' (в оригинале в to '''authenticate''' что правильно но я не знаю русского аналога) у API это использовать клиентские сертификаты.<BR>
  +
Все эти клиентские сертификаты должны быть выпущены одним и тем же СA, который, повторюсь может отличаться от того СА который выпустил сертификат для HTTPS сервера API<BR>
  +
<BR>
  +
  +
Когда используется файл '''kubeconfig''' клиентские сертификаты можно указать примерно так:
  +
<PRE>
  +
kind: Config
  +
users:
  +
- name: green-user
  +
user:
  +
client-certificate: path/to/my/client/cert
  +
client-key: path/to/my/client/key
  +
</PRE>
  +
  +
Kubernetes ожидает что клиентские сертификаты будут созданы определенным образом.
  +
* '''Common Name''' - содержит '''username'''
  +
* '''Organization''' - содержит '''group'''
  +
  +
Если это не то что нужно то вместо клиентских сертификатов нужно использовать аутентифиуирующий прокси (use an authenticating proxy) (но я не знаю как)
  +
  +
Соответственно для авторизации клиентов (пока что это только компоненты кубернетиса) используется '''СА2'''
  +
  +
===The request header certificate authority (or: using an authenticating proxy)===
  +
<PRE>
  +
# API server arguments
  +
--requestheader-allowed-names stringSlice
  +
List of client
  +
certificate common names to allow to provide usernames in headers specified by
  +
--requestheader-username-headers. If empty, any client certificate validated by
  +
the authorities in --requestheader-client-ca-file is allowed.
  +
--requestheader-client-ca-file string
  +
Root certificate bundle to use to verify client certificates on incoming
  +
requests before trusting usernames in headers specified by
  +
--requestheader-username-headers
  +
</PRE>
  +
Другой способ это использовать '''authenticating proxy.'''<BR>
  +
(мне пока что не нужен по тому не перевел)
  +
If you have a lot of opinions about what usernames and groups should be sent to the API server,<BR>
  +
you can set up a proxy which passes usernames & groups to the API server in a HTTP header.<BR>
  +
<BR>
  +
<BR>
  +
The docs basically explain how this works – the proxy uses a client cert to identify itself,
  +
and the --requestheader-client-ca-file tells the API server which CA to use to verify that client cert.<BR>
  +
<BR>
  +
I don’t have too much to say about this except – we learned pretty quickly that having too many auth methods in your API server (“accept client certificates OR an authenticating proxy OR a token OR…“) makes things confusing. It’s probably better to pick a small number (like 1 or 2?) of authentication methods your API server supports because it makes it easier to debug problems and understand your security model.
  +
<BR>
  +
  +
===serviceaccount private keys (which aren’t signed by a certificate authority)===
  +
<PRE>
  +
# API server argument
  +
--service-account-key-file stringArray
  +
File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to
  +
verify ServiceAccount tokens. If unspecified, --tls-private-key-file is used.
  +
The specified file can contain multiple keys, and the flag can be specified
  +
multiple times with different files.
  +
</PRE>
  +
<PRE>
  +
# controller manager argument
  +
--service-account-private-key-file string
  +
Filename containing a PEM-encoded private RSA or ECDSA key used to sign service
  +
account tokens.
  +
</PRE>
  +
'''Controller manager''' подписывает токены сервисного аккаунта закрытым ключом.
  +
  +
The controller manager signs serviceaccount tokens with a private key. <BR>
  +
<BR>
  +
Но в отличии от всех остальных частных ключей в Kubernetes, ключ сервисного аккаунта не поддерживает проверку подписи с помощью СА
  +
<BR>
  +
Это (очевидно) означает что нужно иметь один и тот же закрытый ключ на всех запущенных '''controller manager'''
  +
<BR>
  +
Этот (закрытый) ключ не должен иметь подписи СА и сертификата
  +
и может быть просто создан командой
  +
<PRE>
  +
openssl genrsa -out private.key 4096
  +
</PRE>
  +
и распространен по всем нодам controller manager и API server.
  +
<BR>
  +
<BR>
  +
Дополню:<BR>
  +
Т.е.нужна пара ключей, причем эта пара одна в пределах кластера:
  +
* Для '''API''' сервера нужна публичная часть ключа, которая передается параметром '''--service-account-key-file''' и используется для проверки токенов
  +
* Для '''controller manager''' нужна приватная часть ключа которая используется для подписания токенов
  +
<PRE>
  +
openssl genrsa -out service-account-private.key 4096
  +
</PRE>
  +
<PRE>
  +
openssl rsa -in service-account-private.key -pubout > service-account-public.key
  +
</PRE>
  +
  +
Вот что пишет Джулия:
  +
<PRE>
  +
Using --tls-private-key-file for this seems generally fine to me though,<BR>
  +
as long as you give every API server the same TLS key (which I think you usually would?).<BR>
  +
  +
(I’m assuming here that you have a HA setup where you run more than one API server and more than one controller manager)
  +
  +
If you give 2 different controller managers 2 different keys, they’ll sign serviceaccount tokens with different keys and you’ll end up with invalid serviceaccount tokens (see this issue: https://github.com/kubernetes/kubernetes/issues/22351).<BR>
  +
I think this isn’t ideal (Kubernetes should probably support these keys being issued from a CA like it does for ~every other private key).
  +
  +
  +
From reading the source code I think the reason it’s set up this way is that jwt-go doesn’t support using a CA to check signatures.
  +
</PRE>
  +
  +
==kubelet certificate authorities==
  +
Настройки api для связи с kubelet:
  +
<PRE>
  +
# API server arguments
  +
--kubelet-certificate-authority string Path to a cert file for the certificate authority.
  +
--kubelet-client-certificate string Path to a client cert file for TLS.
  +
--kubelet-client-key string Path to a client key file for TLS.
  +
</PRE>
  +
Настройки kubelet:
  +
<PRE>
  +
# kubelet arguments
  +
--client-ca-file string If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
  +
--tls-cert-file string File containing x509 Certificate used for serving HTTPS (with intermediate certs, if any, concatenated after server cert). If --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to --cert-dir.
  +
--tls-private-key-file string File containing x509 private key matching --tls-cert-file.
  +
</PRE>
  +
Неплохая мысль проверять и аутентифицировать запросы к кублетам так как они могут исполнять произвольный код на нодах (собственно в этом их задача)
  +
  +
По факту тут в настройках 2 СА - аналогично API сервера
  +
  +
* kubelet-certificate-authority - собственно СА которым API сервер подписывает клиентские сертификаты
  +
  +
С другой стороны у '''kubelet'''
  +
* Параметры с '''tls''' - это сертификат HTTP(s) endpoint
  +
* --client-ca-file - это СА с помощью которого можно проверить клиентский сертификат
  +
<PRE>
  +
There are actually 2 CAs here.
  +
I won’t go into too much detail because this is the same as the setup for the APi server – the kubelet has a TLS cert
  +
(that it uses to serve TLS requests) and also supports client cert authentication.
  +
  +
You tell the API server what certificate authority to use to check the kubelet’s TLS cert, and what client certificate to use when talking to the kubelet.
  +
  +
Again these 2 CAs could be totally different from each other.
  +
</PRE>
  +
  +
==so many possible CAs==
  +
<PRE>
  +
So far we have found 5 different certificate authorities you can specify as part of setting up a Kubernetes cluster! They’re all handled independently and in theory they could all be totally different.
  +
  +
I didn’t discuss every single CA setting that Kubernetes supports (there are still more!) but hopefully this gives you some of the tools you need to read the docs about the rest.
  +
  +
Again – it almost certainly doesn’t makes sense to make them all different from each other but I think it’s useful to understand how all this is set up if you have your own requirements around how you want to handle your certificate authorities for Kubernetes and don’t want to do exactly what the docs suggest
  +
</PRE>
   
 
=Ссылки=
  
=Ссылки=

Текущая версия на 15:33, 14 сентября 2022

Заметка о PKI/CA в kubernetes

Эта заметка появилась для того что бы раз и навсегда прояснить какие CA и сертификаты используются в control-plane, для чего они используются и почему именно такие.


Предполагается что у читающего есть базовое понимание TLS/SSL/CA/PKI/OpenSSL


Julia Evans - мой герой! https://jvns.ca/blog/2017/08/05/how-kubernetes-certificates-work/

Структура заметки следующая

  • Первая часть - пример настройки PKI вручную для всех сервисов K8S
  • Вторая часть - заметки которые были написаны в процессе понимания (хронологически она первая но читать ее не обязательно и написано местами сумбурно)


Используется внешний уже настроенный Vault

  • Токен не секретный только в тестовых инсталляциях - в общем случае использовать один рутовый токен для всего плохая идея

Почему возникла эта заметка

Официальная документация гласит:
Kubernetes requires PKI for the following operations:

  • Client certificates for the kubelet to authenticate to the API server
  • Server certificate for the API server endpoint
  • Client certificates for administrators of the cluster to authenticate to the API server
  • Client certificates for the API server to talk to the kubelets
  • Client certificate for the API server to talk to etcd
  • Client certificate/kubeconfig for the controller manager to talk to the API server
  • Client certificate/kubeconfig for the scheduler to talk to the API server.
  • Client and server certificates for the front-proxy

Note: front-proxy certificates are required only if you run kube-proxy to support an extension API server. etcd also implements mutual TLS to authenticate clients and peers.
При этом я не нашел никакой информации о том каким свойствами должны обладать сертификаты, должны ли они быть подписаны одним CA?

Практика

Насколько я могу судить можно использовать следующие CA (которые не обязаны но могут быть одним и тем же CA)

СA0 Доступ к etcd

По сути эта настройка никак не связана с k8s - просто нужны клиентские сертификаты подписанные СА etcd

kube-apiserver

/usr/local/bin/kube-apiserver \
    ...
    --etcd-certfile=/etc/k8s/kube-apiserver/etcd/etcd.k8s.home.pem \
    --etcd-keyfile=/etc/k8s/kube-apiserver/etcd/etcd.k8s.home.key \
    --etcd-servers=${ETCD_SERVER} \
   ...

СA1 Для авторизации клиентов у kube-apiserver

Подготовка PKI

mkdir kube-apiserver/client-auth


Подготовка переменных окружения для PKI



Создание промежуточного CA

PKI_PATH - просто человеко-читаемый путь он может быть строго говоря любым


Создание запроса на сертификат для промежуточного CA



Извлечение CSR из ответа и сохранение в удобном формате



Подписать промежуточный сертификат CA основным CA

(подробнее в статье про Vault PKI https://noname.com.ua/mediawiki/index.php/Vault_PKI)


Извлечение сертификата из ответа и сохранение в удобном формате (PEM)

Это СА для клиентов и именно его использует kube-apiserver для проверки клиентов (если не используется прокси?)


Загрузка подписанного сертификата в Vault



Прописать URL



Создать роль для создания клиентских сертификатов



Выпустить сертификат для system:kube-controller-manager



СA1 где используются сертификаты

kube-apiserver

CA используется для проверки клиентских сертификатов

  • Параметр --client-ca-file
  • Путь к сертификату в моей течтоыой инсталляции /etc/k8s/kube-apiserver/client-auth/ca/pki_intermediate_ca_for_k8s_kube_apiserver_client_auth.pem
  • ключ к этому сертификату хранится в Vault и достать его нельзя - все клиентские сертификаты выписываются с помощью Vault
/usr/local/bin/kube-apiserver \
    ...
    --client-ca-file=/etc/k8s/kube-apiserver/client-auth/ca/pki_intermediate_ca_for_k8s_kube_apiserver_client_auth.pem \
     ...

kube-control-manager

Сертификат подписанный этим СА 

/usr/local/bin/kube-controller-manager \
  ...
  --kubeconfig=/etc/k8s/kube-controller-manager/kube-controller-manager.kubeconfig \
  ...

В файле /etc/k8s/kube-controller-manager/kube-controller-manager.kubeconfig (кроме других параметров) - путь к сертификатам

  • client-certificate: /etc/k8s/kube-controller-manager/kube-apiserver/system:kube-controller-manager.pem
  • client-key: /etc/k8s/kube-controller-manager/kube-apiserver/system:kube-controller-manager.key

В этом сертификате CN это username по сути 

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/k8s/shared/CA/pki_intermediate_ca_for_k8s_kube_apiserver_tls.pem
    server: https://kube-apiserver.az1.k8s.home:6443
  name: kubernetes-the-hard-way
contexts:
- context:
    cluster: kubernetes-the-hard-way
    user: system:kube-controller-manager
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: system:kube-controller-manager
  user:
    client-certificate: /etc/k8s/kube-controller-manager/kube-apiserver/system:kube-controller-manager.pem
    client-key: /etc/k8s/kube-controller-manager/kube-apiserver/system:kube-controller-manager.key

1



СA2 TLS для kube-apiserver

Подготовка PKI

Не останавливаясь подробно на шагах - просто пример конфигурации.



СA2 где используются сертификаты

kube-apiserver

Это серверные сертификаты с CN=доменное имя API сервера нужны собственно для HTTPS 

/usr/local/bin/kube-apiserver \
    ...
    --tls-cert-file=/etc/k8s/kube-apiserver/tls/kube-apiserver.az1.k8s.home.pem \
    --tls-private-key-file=/etc/k8s/kube-apiserver/tls/kube-apiserver.az1.k8s.home.key \
   ...

kube-controller-manager

CA указан в клиентах что бы они могли проверить сертификат сервера 

/usr/local/bin/kube-controller-manager \
  ...
  --kubeconfig=/etc/k8s/kube-controller-manager/kube-controller-manager.kubeconfig \
  ...

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/k8s/shared/CA/pki_intermediate_ca_for_k8s_kube_apiserver_tls.pem
    server: https://kube-apiserver.az1.k8s.home:6443
  name: kubernetes-the-hard-way

CA3 TLS для kube-control-manager

Подготовка PKI

Настройка полностью аналогична CA2 - но используется для создания серверных сертификатов kube-controller-manager

СA3 где используются сертификаты

kube-controller-manager

/usr/local/bin/kube-controller-manager \
  --bind-address=0.0.0.0 \
  --tls-cert-file=/etc/k8s/kube-controller-manager/tls/kube-controller-manager.az1.k8s.home.pem \
  --tls-private-key-file=/etc/k8s/kube-controller-manager/tls/kube-controller-manager.az1.k8s.home.key \
...

kube-apiserver

kube-controller-manager

kubelet

  • ИМЕН НОД ВАЖНЫ

https://kubernetes.io/docs/reference/access-authn-authz/node/

Разбор от Джулии с моими комментариями

Вот что пишет по этому поводу Джулия (перевод мой): 

В различных компонентах Kubernetes есть ТЫЩИ разных мест,
где вы можете разместить a certificate/certificate authority.
Когда мы настраивали кластер, я чувствовал, что существует 
около 10 миллиардов различных аргументов командной 
строки для сертификатов, ключей и центров сертификации, и 
я не понимал, как все они сочетаются друг с другом.

На самом деле нет 10 миллиардов аргументов командной строки, 
но их довольно много. Например! Давайте просто посмотрим на 
аргументы командной строки для сервера API.

У API сервера 16 (ШЕСТНАДЦАТЬ, КАРЛ) аргументов которые так или иначе относятся к шифрованию: 

--cert-dir string The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/run/kubernetes")
--client-ca-file string If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client                     certificate.
--etcd-certfile string SSL certification file used to secure etcd communication.
--etcd-keyfile string SSL key file used to secure etcd communication.
--etcd-cafile string                        SSL Certificate Authority file used to secure etcd communication.
--kubelet-certificate-authority string      Path to a cert file for the certificate authority.
--kubelet-client-certificate string         Path to a client cert file for TLS.
--kubelet-client-key string                 Path to a client key file for TLS.
--proxy-client-cert-file string             Client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins. It is expected that this cert includes a signature from the CA in the --requestheader-client-ca-file flag. That CA is published in the 'extension-apiserver-authentication' configmap in the kube-system namespace. Components recieving calls from kube-aggregator should use that CA to perform their half of the mutual TLS verification.
--proxy-client-key-file string              Private key for the client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins.
--requestheader-allowed-names stringSlice   List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed.
--requestheader-client-ca-file string       Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers
--service-account-key-file stringArray      File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. If unspecified, --tls-private-key-file is used. The specified file can contain multiple keys, and the flag can be specified multiple times with different files.
--ssh-keyfile string                        If non-empty, use secure SSH proxy to the nodes, using this user keyfile
--tls-ca-file string                        If set, this certificate authority will used for secure access from Admission Controllers. This must be a valid PEM-encoded CA bundle. Alternatively, the certificate authority can be appended to the certificate provided by --tls-cert-file.
--tls-cert-file string                      File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to /var/run/kubernetes.
--tls-private-key-file string               File containing the default x509 private key matching --tls-cert-file.
--tls-sni-cert-key namedCertKey             A pair of x509 certificate

Отдельно радует именование, блять, параметров: ca-file или cafile???
А может лучше certificate-authority.
Не можем решить и оставим все три варианта!
Четыреждыблядская ярость. На этом месте я подумал что может ну его нахуй и не так уж сильно я хочу изучить Kubernetes.

Еще информация к размышлению (да я тоже был очень удивлен!): 

One thing I found surprising about this is – almost everything else in the universe that uses TLS will look in /etc/ssl to find a list of certificate authorities the computer trusts by default. But Kubernetes doesn’t do that, instead it mandates “no, you have to say exactly which CA issued the API server’s TLS cert”.

Другими словами использовать добавленные в систему доверенные CA не получится.

Нужен ли единый CA для кластера (нет)

Такой вопрос возник не только у меня: 

Does a Kubernetes cluster have to have a single root certificate authority? (no)

Дальше мой вольный перевод:

Если вы прочитали кучу мануалов про установку кластера, то в каждом из них есть шаг "Постройте свой СА" ("set up a certificate authority".
Kelsey Hightower’s c его прекрасной, но недостаточно подробной инструкцией “kubernetes the hard way” делает это на втором шаге.
инструкция гласит 

Every Kubernetes cluster has a cluster root Certificate Authority (CA).
The CA is generally used by cluster components to validate the API server’s certificate, by the API server to validate kubelet client certificates, etc.

В общих чертах это работает так

  • Настройте свой центр выдачи сертефикатов (обычно предлагают скрипты cfssl)
  • Нагенерите сертификатов подписанных своим СА для разных частей кластера

Тут сразу же возникает вопрос - а что делать если я не хочу городить новый PKI для каждого кластера
Фраза (“every Kubernetes cluster has a [single] cluster root Certificate Authority”) ошибочна полностью - можно как использовать один CA для нескольких кластеров так и несколько СА для одного кластера.

kube-apiserver

The API server’s TLS certificate (and certificate authority)

Параметры

  • --tls-cert-file string File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to /var/run/kubernetes.
  • --tls-private-key-filestring File containing the default x509 private key matching --tls-cert-file.

Относительно простая часть - эти параметры отвечают за серверный сертификат и его ключ который будет на Endpoint. В общем случае неплохо сделать так что бы curl мог подключиться туда без проблем - т е добавить CА который подписал этот сертификат в доверенные (или сделать bundle с промежуточным CA).
Так же важно что бы тут был правильныйдомен(и IP в SAN)

После устновки TLS для API требуется подготовить kubeconfig для других компонетов (таких как kubelet and kubectl) которым требуется коммуникация с API.

kubeconfig выглядит примерно так 

current-context: my-context
apiVersion: v1
clusters:
- cluster:
    certificate-authority: /path/to/my/ca.crt # Путь к CA  которым был подписан сертификат для API указанный в параметре --tls-cert-file kube-apiserver
    server: https://horse.org:4443            # Доменное имя должно быьть указано в сертификате, который  указан в параметре --tls-cert-file kube-apiserver
  name: my-cluster
kind: Config
users:
- name: green-user
  user:
    client-certificate: path/to/my/client/cert # РАССМОТРЕНО НИЖЕ
    client-key: path/to/my/client/key          #  РАССМОТРЕНО НИЖЕ

Напоминаю что системные СА игнорируются и нужно ЯВНО указать путь к СА которым подписан сертификат

Вопросы пока без ответа

  • current-context
  • name: my-cluster



Файл kubeconfig передается компонентам как парамерт --kubeconfig /path/to/kubeconfig.yaml

Итого - первый СА это СА для TLS на API (при этом сам корневой сертификат используется только для проверки подлиности сервера а его ключ нигде не присутствует. (назовем этот СА - СА1) Этот СА может использоваться ТОЛЬКО для указанных целей и не совпадать ни с одним другим СА кластера.

The API server client certificate authority (+ certificates)

--client-ca-file string    
    If set, any request presenting a client certificate signed by one of the
    authorities in the client-ca-file is authenticated with an identity
    corresponding to the CommonName of the client certificate.

Один из возможных способов для компонентов Kubernetes авторизоваться (в оригинале в to authenticate что правильно но я не знаю русского аналога) у API это использовать клиентские сертификаты.
Все эти клиентские сертификаты должны быть выпущены одним и тем же СA, который, повторюсь может отличаться от того СА который выпустил сертификат для HTTPS сервера API

Когда используется файл kubeconfig клиентские сертификаты можно указать примерно так: 

kind: Config
users:
- name: green-user
  user:
    client-certificate: path/to/my/client/cert
    client-key: path/to/my/client/key

Kubernetes ожидает что клиентские сертификаты будут созданы определенным образом.

  • Common Name - содержит username
  • Organization - содержит group

Если это не то что нужно то вместо клиентских сертификатов нужно использовать аутентифиуирующий прокси (use an authenticating proxy) (но я не знаю как)

Соответственно для авторизации клиентов (пока что это только компоненты кубернетиса) используется СА2

The request header certificate authority (or: using an authenticating proxy)

# API server arguments
--requestheader-allowed-names stringSlice                 
  	    List of client
        certificate common names to allow to provide usernames in headers specified by
        --requestheader-username-headers. If empty, any client certificate validated by
        the authorities in --requestheader-client-ca-file is allowed.
--requestheader-client-ca-file string                     
        Root certificate bundle to use to verify client certificates on incoming
        requests before trusting usernames in headers specified by
        --requestheader-username-headers

Другой способ это использовать authenticating proxy.
(мне пока что не нужен по тому не перевел) If you have a lot of opinions about what usernames and groups should be sent to the API server,
you can set up a proxy which passes usernames & groups to the API server in a HTTP header.


The docs basically explain how this works – the proxy uses a client cert to identify itself, and the --requestheader-client-ca-file tells the API server which CA to use to verify that client cert.

I don’t have too much to say about this except – we learned pretty quickly that having too many auth methods in your API server (“accept client certificates OR an authenticating proxy OR a token OR…“) makes things confusing. It’s probably better to pick a small number (like 1 or 2?) of authentication methods your API server supports because it makes it easier to debug problems and understand your security model.

serviceaccount private keys (which aren’t signed by a certificate authority)

# API server argument
--service-account-key-file stringArray
    File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to
    verify ServiceAccount tokens. If unspecified, --tls-private-key-file is used.
    The specified file can contain multiple keys, and the flag can be specified
    multiple times with different files.

# controller manager argument
--service-account-private-key-file string
    Filename containing a PEM-encoded private RSA or ECDSA key used to sign service
    account tokens.

Controller manager подписывает токены сервисного аккаунта закрытым ключом.

The controller manager signs serviceaccount tokens with a private key.

Но в отличии от всех остальных частных ключей в Kubernetes, ключ сервисного аккаунта не поддерживает проверку подписи с помощью СА
Это (очевидно) означает что нужно иметь один и тот же закрытый ключ на всех запущенных controller manager
Этот (закрытый) ключ не должен иметь подписи СА и сертификата и может быть просто создан командой 

openssl genrsa -out private.key 4096

и распространен по всем нодам controller manager и API server.

Дополню:
Т.е.нужна пара ключей, причем эта пара одна в пределах кластера:

  • Для API сервера нужна публичная часть ключа, которая передается параметром --service-account-key-file и используется для проверки токенов
  • Для controller manager нужна приватная часть ключа которая используется для подписания токенов
openssl genrsa -out service-account-private.key 4096

openssl rsa -in service-account-private.key  -pubout > service-account-public.key

Вот что пишет Джулия: 

Using --tls-private-key-file for this seems generally fine to me though,<BR>
as long as you give every API server the same TLS key (which I think you usually would?).<BR>

(I’m assuming here that you have a HA setup where you run more than one API server and more than one controller manager)

If you give 2 different controller managers 2 different keys, they’ll sign serviceaccount tokens with different keys and you’ll end up with invalid serviceaccount tokens (see this issue: https://github.com/kubernetes/kubernetes/issues/22351).<BR>
I think this isn’t ideal (Kubernetes should probably support these keys being issued from a CA like it does for ~every other private key).


From reading the source code I think the reason it’s set up this way is that jwt-go doesn’t support using a CA to check signatures.

kubelet certificate authorities

Настройки api для связи с kubelet: 

# API server arguments
--kubelet-certificate-authority string    Path to a cert file for the certificate authority.
--kubelet-client-certificate string       Path to a client cert file for TLS.
--kubelet-client-key string               Path to a client key file for TLS.

Настройки kubelet: 

# kubelet arguments
--client-ca-file string                   If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
--tls-cert-file string                    File containing x509 Certificate used for serving HTTPS (with intermediate certs, if any, concatenated after server cert). If --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to --cert-dir.
--tls-private-key-file string             File containing x509 private key matching --tls-cert-file.

Неплохая мысль проверять и аутентифицировать запросы к кублетам так как они могут исполнять произвольный код на нодах (собственно в этом их задача)

По факту тут в настройках 2 СА - аналогично API сервера

  • kubelet-certificate-authority - собственно СА которым API сервер подписывает клиентские сертификаты

С другой стороны у kubelet

  • Параметры с tls - это сертификат HTTP(s) endpoint
  • --client-ca-file - это СА с помощью которого можно проверить клиентский сертификат
There are actually 2 CAs here. 
I won’t go into too much detail because this is the same as the setup for the APi server – the kubelet has a TLS cert 
(that it uses to serve TLS requests) and also supports client cert authentication.

You tell the API server what certificate authority to use to check the kubelet’s TLS cert, and what client certificate to use when talking to the kubelet.

Again these 2 CAs could be totally different from each other.

so many possible CAs

So far we have found 5 different certificate authorities you can specify as part of setting up a Kubernetes cluster! They’re all handled independently and in theory they could all be totally different.

I didn’t discuss every single CA setting that Kubernetes supports (there are still more!) but hopefully this gives you some of the tools you need to read the docs about the rest.

Again – it almost certainly doesn’t makes sense to make them all different from each other but I think it’s useful to understand how all this is set up if you have your own requirements around how you want to handle your certificate authorities for Kubernetes and don’t want to do exactly what the docs suggest

Ссылки

Источник — https://noname.com.ua/mediawiki/index.php?title=K8s-pki&oldid=9950