Vault PKI Intermediate CAs for ALL SERVICES Kubernetes the hard way v2: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
(Новая страница: «Категория:K8s Категория:Hashicorp_Vault Категория:Vault Категория:Linux Категория:Kubernetes the ha...»)
 
 
(не показано 226 промежуточных версий этого же участника)
Строка 6: Строка 6:
 
[[Категория:kube-apiserver]]
  
[[Категория:kube-apiserver]]
   
−
=Создание СА для работы кластера K8s - Kube-Apiserver=
  
 
Эта страница - часть большой статьи про CA используемые в k8s: [[Vault_PKI_Kubernetes_the_hard_way_v2]]
  
Эта страница - часть большой статьи про CA используемые в k8s: [[Vault_PKI_Kubernetes_the_hard_way_v2]]
   
  +
  +
=Прежде чем начать читать=
  +
Эта часть описывает какие именно сертификаты и СА для чего используются разными сервисами - ее можно прочитать перед тем как настаивать <code>Vault</code> для понимания того что и зачем настраивается или после.
  +
<br>
  +
[[Vault_PKI_Intermediate_SETUP_CAs_for_ALL_SERVICES_Kubernetes_the_hard_way_v2|Описание настойки <code>Vault</code> для выпуска сертификатов]]
  +
  +
=Некоторые термины и замечания=
  +
* <code>CA</code>: '''certificate authority''' или '''certification authority''' ( на русском это звучит как Центр Сертефикации)
  +
В контексте документа может иметь несколько возможных значений - как собственно центр выпуска сертификатов, так и сам корневой (или промежуточный сертификат) этого центра. По сути, сертификат СА, который используется для подписания клиентских и серверных сертификатом не только не является секретным, но наоборот должен быть доступен для доступа так как именно он используется для проверки валидности выпущенных сертификатов
  +
<br>
  +
  +
В случае с PKI на основе <code>Vault</code> СA доступны для скачивания без авторизации.
  +
  +
<br>
  +
<br>
  +
Есть 2 типа сертификатов (конечно их больше но в K8s используется 2 типа). Потому в целом (кроме <code>etcd</code>) есть разделение СА в том числе и по типу выпускаемых сертификатов
  +
* <code>client_auth</code> - этот суффикс у СА используется в значении "сертификаты используются для авторизации" (другими словами - не используются для организации <code>http</code>)
  +
* <code>tls</code> - этот суффикс у СА используется в значении "сертификаты используются для организации <code>https/TLS</code>"
  +
  +
  +
* В целом, если не использовать <code>Vault</code> а использовать другой PKI, будь то на основе <code>OpenSSL</code> или чего-то другого ничего принципиально не меняется, и ничего специфичного для PKI <code>Vault</code> в документе нет
  +
  +
* В этом разделе нет команд по получению сертификатов или настройке PKI, а только описание параметров сервисов, их назначения и свойства сертификатов которые используются.
  +
  +
В целом для лучшего понимания можно держать в голове такую схему
  +
  +
<PRE>
  +
  +
  +
+-------------+ +---------------------------------------------+ +-------------------------------------------------+
  +
| Корневой CA | --------> им подписан -------> |Промежуточный CA для сервиса X и пользования | -------------> им подписан ----------> | Конечный сертификат которым пользуется сервис Y |
  +
+-------------+ (процедура подписания ) +---------------------------------------------+ (процедура подписания скрыта ) +-------------------------------------------------+
  +
(скрыта внутри Vault и ) (внутри Vault и требует авторизации )
  +
(требует рутовый токен от Vault) (с логином и паролем, который выдается )
  +
(тому сервису которому нужен сертификат)
  +
</PRE>
  +
  +
Пример 1
 
<BR>
  
<BR>
  +
* Сервису <code>kubelet </code> нужен сертификат для того что бы авторизоваться у <code>kube-apiserver</code>
−
Задача - настроить промежуточный СА для работы сервиса kube-apiserver
  
  +
* Создается промежуточный CA (внутри Vault) который будет иметь возможность выписывать такие сертификаты, в этом пример это будет СА <code>k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/</code>
  +
* Сертификат этого промежуточного СА подписывается (или иногда говорят "заверяется", что в контексте SSL синонимы) Корневым СА (на схеме)
  +
** <code>k8s_pki_intermediate_ca_for_service_</code> - префикс общий для всех СA которые используются для K8s (в случае <code>Vault</code> используется например для более чем одного кластера, или еще зачем-то)
  +
** <code>kube_apiserver</code> - имя сервиса, который будет пользоваться сертификатами, в данном контексте "пользоваться" означает то что <code>kube-apiserver</code>будет проверять эти сертификаты, а не то что они будут непосредственно указаны в его конфигурационных файлах.
  +
** <code>client_auth</code> - назначение сертификатов которые будут создаваться с помощью этого CA
  +
** Создаются правила пользования этим СА - какие пользователи и с какими параметрами могут получать сертификаты для авторизации у <code>kube-apiserver</code>, ограничения касаются CN (подробнее об этом - о настройке PKI для <code>Vault</code>, как например [[Vault_PKI_Intermediate_ca_etcd_Roles_and_permissions_for_real_cluster_Kubernetes_the_hard_way_v2|настроено получение сертификатов для <code>Etcd</code>]]
  +
** Данные для авторизации выдаются сервису, которому нужен сертификат (в примере - <code>kubelet</code>) который используя API <code>Vault</code> может сам выпустить сертификат (с учетом ограничений CN) и при необходимости перевыпустить его.
  +
** Автоматизация перевыпуска сертификатов - дело будущей настройки сервисов и будет описана в других разделах
  +
  +
<BR>
  +
<BR>
  +
Пример 2
  +
<BR>
  +
* Сервису <code>kube-apiserver</code> нужно открыть порт и принимать <code>HTTPS/TLS</code> подключения (авторизация после подключения в этом примере пропущена)
  +
* Для этого требуется серверный сертификат
  +
* Для выпуска таких сертификатов создается СА <code>k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/</code>, промежуточный сертификат заверяется корневым
  +
* отличие - в том что он предназначен для <code>HTTPS/TLS</code> и имеет другой суффикс
  +
* для сервиса <code>kube-apiserver</code> создается пользователь и пароль в <code>Vault</code> (с ограничениями на CN)
  +
* имея доступ к API <code>Vault</code>, сервис <code>kube-apiserver</code> может выписать себе сертификат с нужным CN (в пределах ограничений) а так же перевыпустить просроченный сертификат
  +
<BR>
  +
<BR>
  +
Отличие между примерами в том, что хотя в обоих случаях СА имеют в имени <code>kube-apiserver</code>
  +
* k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth
  +
* k8s_pki_intermediate_ca_for_service_kube_apiserver_tls
  +
В первом пример сертификаты выписанные CA с пометкой '''client_auth''' используются для того что бы подключиться к <code>kube-apiserver</code> и не фигурируют в его конфигах
  +
Во втором же примере сертификаты выписанные СА с пометкой '''tls''' используются самим <code>kube-apiserver</code>
  +
  +
=Создание СА для работы кластера K8s=
  +
==Соглашение о путях к файлам==
  +
* Путь к СА: <code>/etc/k8s/shared/certs/CA</code>
  +
* Все файлы СА (далее по тексту просто СА) можно загрузить из <code>Vault</code> в любой момент, без авторизации. Эти файлы СА (БЕЗ ключа!) не являются секретными, и могут использоваться только для проверки сертификатов (что бы проверить требуется вся цепочка - Корневой CA -- Промежуточный СА -- Сертификат
  +
* Скрипт загрузки проходится по списку сервисов и загружает с соответствующих endpoints СA в файлы :
  +
#kube_apiserver
  +
#kube_controller_manager
  +
#kube_scheduler
  +
#kubelet
  +
  +
в <code>Vault</code> и загружает промежуточные сертификаты в директорию<code>/etc/k8s/shared/certs/CA</code>
  +
{{#spoiler:show=Скрипт загрузки промежуточных CA|
  +
  +
<PRE>
  +
#!/bin/bash
  +
  +
set -eu${DEBUG:+x}
  +
  +
VAULT_ADDRESS="http://vault.home:8200"
  +
  +
SERVICE_NAMES="kubelet kube-apiserver kube-controller-manager kube-scheduler"
  +
USAGES="TLS CLIENT_AUTH"
  +
PKI_PATH_PREFIX="k8s_pki_intermediate_ca_for_service"
  +
CA_PATH="/etc/k8s/shared/certs/CA"
  +
mkdir -p "${CA_PATH}"
  +
  +
for SERVICE_NAME in ${SERVICE_NAMES};
  +
do
  +
for USAGE in ${USAGES};
  +
do
  +
SERVICE_NAME_UNDERSCORE=$(echo ${SERVICE_NAME} | sed 's/-/_/g')
  +
USAGE_LOWERCASE=$(echo "${USAGE,,}")
  +
USAGE_LOWERCASE=$(echo $USAGE_LOWERCASE | sed 's/-/_/g')
  +
  +
PKI_PATH="${PKI_PATH_PREFIX}_${SERVICE_NAME_UNDERSCORE}_${USAGE_LOWERCASE}"
  +
echo curl "${VAULT_ADDRESS}/v1/${PKI_PATH}/ca"
  +
echo "-----BEGIN CERTIFICATE-----" > "${CA_PATH}/${PKI_PATH}.pem" && \
  +
curl "${VAULT_ADDRESS}/v1/${PKI_PATH}/ca" | base64 >> "${CA_PATH}/${PKI_PATH}.pem" && \
  +
echo "-----END CERTIFICATE-----" >> "${CA_PATH}/${PKI_PATH}.pem"
  +
done
  +
done
  +
</PRE>
  +
}}
  +
  +
  +
<code>K8s</code> использует СА для выписывания сертификатов 2 типов
  +
* "Обычные" серверные сертификаты (<code>CN = domain</code>)
  +
* Сертификаты используемые для авторизации - клиентские (<code>CN=username</code>, <code>O=groupname</code>)
  +
  +
  +
  +
Всего в Vault настроены такие СА:
  +
<PRE>
  +
k8s_pki_intermediate_ca_for_service_etcd/ pki pki_13a87e77 PKI Intermediate CA for ETCd service
  +
k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/ pki pki_622072da PKI Intermediate CA for K8S: kube-apiserver CLIENT_AUTH
  +
k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/ pki pki_d8737474 PKI Intermediate CA for K8S: kube-apiserver TLS
  +
k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/ pki pki_34a63553 PKI Intermediate CA for K8S: kube-controller-manager TLS
  +
k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/ pki pki_5b5f53f5 PKI Intermediate CA for K8S: kube-scheduler TLS
  +
k8s_pki_intermediate_ca_for_service_kubelet_client_auth/ pki pki_4f1df8fd PKI Intermediate CA for K8S: kubelet CLIENT_AUTH
  +
k8s_pki_intermediate_ca_for_service_kubelet_tls/ pki pki_47e7182a PKI Intermediate CA for K8S: kubelet TLS
  +
k8s_pki_root_ca/ pki pki_8b6cae1e PKI k8s Root CA
  +
</PRE>
  +
  +
=Полный список <code>СА</code> (промежуточных СА!)=
  +
  +
* Всего существует 8 СА которые используются в этой инсталляции (один из них - корневой СА). <br>
 
<br>
  
<br>
  +
Если верить документации, то это не предел - каждый файл с CA в настройках сервисов может содержать <br>
−
[[Vault_PKI_Intermediate_ca_etcd_Kubernetes_the_hard_way_v2|CA для <code>ETCd</code>]]
  
  +
более одного сертификата, другими словами 2 процесса <code>kube-apiserver</code> вполне могут использовать разные CA<br>
−
=Конфигурация Vault=
  
  +
−
* Стараюсь именовать path более-менее осмысленно ('''k8s_pki_intermediate_ca_for_service_etcd''')
  
  +
В частных случаях можно упростить настройку, и вообще использовать 1 СА<br>
−
* PKI (последняя строка) здесь - это тип секрета
  
  +
Эта инсталляция подразумевает настойку PKI средней сложности.
  +
<br>
  +
  +
=<code>k8s_pki_intermediate_ca_for_service_etcd/</code>=
  +
  +
<code>k8s_pki_intermediate_ca_for_service_etcd/</code> - используется для клиентских и серверных сертификатов <code>etcd</code>. Строго говоря, не является частью k8s и настраивается отдельно ([[Vault_PKI_Intermediate_ca_etcd_Kubernetes_the_hard_way_v2|Настройка PKI для <code>etcd</code>]])
  +
* для шифрования endpoints
  +
* для авторизации клиентов
  +
  +
=<code>k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/</code><BR><BR><code>k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/</code>=
  +
  +
* <code>k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/</code> - используется для клиентских сертефикатов <code>kube-apiserver</code>, по которым API проверяет права пользователей.
  +
* <code>k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/</code> Используется для обеспечения https при подключении к <code>kube-apiserver</code>. При этом происходит двухсторонняя проверка
  +
** Все клиенты (как сервисы, часть k8s, например <code>kube-controller-manager</code>, <code>kube-scheduler</code>, <code>kubectl</code> так и для администрирования) должны обладать CA (который как и прочие СА не является секретным), для того что бы иметь возможность проверить кластер, другими словами быть уверенным в том что подключаются туда куда ожидают. <br>
  +
Часть <code>kubeconfig</code> отвечающая за этот сертификат:
 
<PRE>
  
<PRE>
  +
clusters:
−
vault \
  
  +
- cluster:
−
secrets \
  
  +
certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem
−
enable \
  
  +
server: https://kube-apiserver.k8s.cluster.home:443
−
-path=k8s_pki_intermediate_ca_for_service_etcd \
  
−
-description="PKI Intermediate CA for ETCd service" \
  
−
-max-lease-ttl="175200h" \
  
−
pki
  
 
</PRE>
  
</PRE>
  +
** Со своей стороны сервер проверяет как то что сертефикат клиента подписан правильным СА (<code>k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/</code>), так и поля <code>CN</code> <code>O</code> в сертификате, которые используются как имя пользователя и группа. Имена групп выбраны не случайно - для них уже есть (или можно создать свои!) <code>ClusterRoleBindings</code>
  +
  +
=<code>k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/</code>=
  +
* <code>k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/</code> - используется для обеспечения https, серверные сетефикаты для <code>kube-controller-manager</code> (Серверные сертификаты нужны для API)
  +
  +
=<code>k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/</code>=
  +
* <code>k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/</code> - используется для обеспечения https, серверные сетефикаты для <code>kube-scheduler</code> (Серверные сертификаты нужны для API)
  +
  +
=<code>k8s_pki_intermediate_ca_for_service_kubelet_client_auth/<BR></BR></code> <code>k8s_pki_intermediate_ca_for_service_kubelet_tls/</code>=
  +
  +
  +
<code>k8s_pki_intermediate_ca_for_service_kubelet_client_auth/</code> kubelet в целом устроен аналогично <code>kube-apiserver</code>, и использует 2 СА - один для авторизации клиентов (в случае с <code>kubelet</code> клиентом выступает <code>kube-apiserver</code>), а второй CA используется для обеспечения https
  +
  +
* У <code>kube-apiserver</code> есть настройка <code>--kubelet-certificate-authority</code> - это файл СА <code>k8s_pki_intermediate_ca_for_service_kubelet_tls/</code> (другими словами, это тот СА который выписал '''серверный''' сертификат для обеспечения <code>HTTPS/TLS</code> API <code>kubelet</code> ( Порт 10250). <br>
  +
Просмотреть содержимое можно например командой
 
<PRE>
  
<PRE>
  +
openssl s_client -connect 127.0.0.1:10250
−
Success! Enabled the pki secrets engine at: k8s_pki_intermediate_ca_for_service_etcd/
  
 
</PRE>
  
</PRE>
  +
Используя СА <code>k8s_pki_intermediate_ca_for_service_kubelet_tls</code> <code>kube-apiserver</code> может
  +
точно знать что он обращается к нужному <code>kubelet</code>, так как его серверный сертефикат подписан этим СА
   
  +
−
=Генерация запроса на сертификат для промежуточного CA=
  
  +
* <code>--kubelet-client-certificate</code><code>--kubelet-client-key</code> содрежат сертификат, выписанный помощью СА <code>k8s_pki_intermediate_ca_for_service_kubelet_client_auth/</code> и содержат имя пользователя и группу с которыми <code>kube-apiserver авторизуется</code> у <code>kubelet</code><br>
−
'''Важно - суффикс internal (pki_intermediate_ca/intermediate/generate/internal) означает что сертефикат нельзя будет использовать за пределами Vault'''
  
  +
<br>
−
<BR>В этом примере и не планируется такое использование, но если такая необходимость есть то следует использовать суффикс ''''' exported '''''
  
  +
Например: <code>O = system:masters</code>, <code>OU = system</code>, <code>CN = kube-apiserver-to-kubelet</code>
  +
<br>
  +
<br>При этом по-умолчанию соответствующие <code>ClustetRoleBinding</code> отсутствуют, и перед подключением <code>kubelet</code> их требуется создать дополнительно. (эта часть настройки выполняется при конфигурировании <code>kube-apiserver</code>
  +
  +
  +
* <code>k8s_pki_intermediate_ca_for_service_kubelet_tls/</code> - используется для обеспечения https, серверные сетефикаты
  +
  +
=<code>k8s_pki_root_ca/</code>=
  +
* <code>k8s_pki_root_ca/</code> - это корневой СА которым подписаны все промежуточные СА, и его сертификат СА обязательно требуется распространить по всем хостам так как он является полностью доверенным (в пределах этой инсталляции, конечно)
  +
  +
=Полный список сертификатов с кратким описанием=
  +
Это CA (в <code>VAULT</code>, c именами и описаниями) которые используются для выпуска сертификатов для k8s)
 
<PRE>
  
<PRE>
  +
k8s_pki_intermediate_ca_for_service_etcd/ pki pki_13a87e77 PKI Intermediate CA for ETCd service
−
vault \
  
  +
k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/ pki pki_622072da PKI Intermediate CA for K8S: kube-apiserver CLIENT_AUTH
−
write \
  
  +
k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/ pki pki_d8737474 PKI Intermediate CA for K8S: kube-apiserver TLS
−
-format=json \
  
  +
k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/ pki pki_34a63553 PKI Intermediate CA for K8S: kube-controller-manager TLS
−
k8s_pki_intermediate_ca_for_service_etcd/intermediate/generate/internal \
  
  +
k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/ pki pki_5b5f53f5 PKI Intermediate CA for K8S: kube-scheduler TLS
−
common_name="Intermediate CA for service ETCd" \
  
  +
k8s_pki_intermediate_ca_for_service_kubelet_client_auth/ pki pki_4f1df8fd PKI Intermediate CA for K8S: kubelet CLIENT_AUTH
−
country="Ukraine" \
  
  +
k8s_pki_intermediate_ca_for_service_kubelet_tls/ pki pki_47e7182a PKI Intermediate CA for K8S: kubelet TLS
−
locality="Kharkov" \
  
−
street_address="Lui Pastera st. 322 app. 131" \
  
−
postal_code="61172" \
  
−
organization="K8s The Hardest Way Labs" \
  
−
ou="IT" \
  
−
ttl="175200h" > k8s_pki_intermediate_ca_for_service_etcd_csr.json
  
 
</PRE>
  
</PRE>
   
  +
Note: так как префикс <code>k8s_pki_intermediate_ca_for_service_</code> в именовании CA общий, то в таблице для удобства форматирования он опущен
−
Если используется экспортируемый сертификат то нужно сохранить ключ
  
  +
  +
  +
==<code>kube-apiserver</code>==
  +
{| class="wikitable sortable"
  +
|+ Сертификаты K8s <code> kube-apiserver</code>
  +
|-
  +
! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Тип сертификата (серверный/клиентский/CA) !! Назначение !! Subject и подробности
  +
|-
  +
| <code>kube-apiserver</code>
  +
|| <code>--etcd-certfile</code><br><code>--etcd-keyfile</code>
  +
|| <code>etcd</code>
  +
|| Клиентский <br>TLS Web Client <br>Authentication
  +
|| Авторизация в <code>etcd</code>. В зависимости от настроек содержит имя пользователя <br> если etcd настроен на такой тип авторизации, используется именно такой способ: ([[Kubernetes_the_hard_way_etcd_setup#.D0.90.D0.B2.D1.82.D0.BE.D1.80.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D1.8F_.D0.BD.D0.B0_.D0.BE.D1.81.D0.BD.D0.BE.D0.B2.D0.B5_.D1.81.D0.B5.D1.80.D1.82.D0.B8.D1.84.D0.B8.D0.BA.D0.B0.D1.82.D0.BE.D0.B2|<code>etcd</code>: авторизация с использованием сертификатов]])
  +
||<PRE>
  +
openssl x509 -noout -text -in /etc/k8s/kube-apiserver/certs/etcd/kube-apiserver.pem
  +
</PRE>
  +
<PRE>
  +
Certificate:
  +
Data:
  +
Version: 3 (0x2)
  +
Serial Number:
  +
56:ce:57:67:7d:9b:54:76:6d:60:51:4a:0c:09:c7:11:ac:f1:95:3b
  +
Signature Algorithm: sha256WithRSAEncryption
  +
Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, postalCode = 61172, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service ETCd
  +
Validity
  +
Not Before: Oct 17 15:23:37 2022 GMT
  +
Not After : Oct 16 15:24:04 2027 GMT
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st 322 app. 311, postalCode = 61172, O = Home Network, OU = IT, CN = kube-apiserver-1
  +
X509v3 extensions:
  +
X509v3 Key Usage: critical
  +
Digital Signature, Key Encipherment
  +
X509v3 Extended Key Usage:
  +
TLS Web Client Authentication
  +
X509v3 Subject Key Identifier:
  +
F8:E5:28:79:2F:4E:99:EA:BE:43:B7:CA:6C:1B:20:65:E6:0B:B3:72
  +
X509v3 Authority Key Identifier:
  +
60:41:31:79:58:90:A9:63:62:C2:26:FD:8F:02:B6:07:1A:1D:5C:50
  +
Authority Information Access:
  +
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_etcd/ca
  +
X509v3 Subject Alternative Name:
  +
DNS:kube-apiserver-1
  +
X509v3 CRL Distribution Points:
  +
Full Name:
  +
URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_etcd/crl
  +
  +
</PRE>
  +
|-
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
| <code>kube-apiserver</code>
  +
|| <code>--tls-cert-file</code><br> <code>--tls-private-key-file</code><br>
  +
|| <code>kube_apiserver_tls/</code>
  +
|| Серверный<br>TLS Web Server<br>Authentication
  +
|| <code>HTTPS</code> для API
  +
|| Можно получить <PRE>netstat -ntpl | grep kube-api </PRE>
 
<PRE>
  
<PRE>
  +
tcp 0 0 10.0.12.1:6443 0.0.0.0:* LISTEN 85224/kube-apiserve
−
cat \
  
−
k8s_pki_intermediate_ca_for_service_etcd_csr.json | \
  
−
jq -r '.data.private_key' >> k8s_pki_intermediate_ca_for_service_etcd_certificate.key
  
 
</PRE>
  
</PRE>
  +
Или взять из параметров <code>kube-apiserver</code><br>
  +
Обратить внимание - в Alt Names прописан как основной домен ('''kube-apiserver.az1.k8s.cluster.home'''), так и домен балансера ('''kube-apiserver.k8s.cluster.home''') а так же адреса по которым может быть доступен сервис. Адрес '''10.80.0.1''' указывается в настройках <code>kube-apiserver</code>
  +
* DNS:kube-apiserver.az1.k8s.cluster.home
  +
* DNS:kube-apiserver.k8s.cluster.home
  +
* DNS:kubernetes
  +
* DNS:kubernetes.cluster.home
  +
* IP Address:10.0.12.1
  +
* IP Address:10.80.0.1
  +
* IP Address:127.0.0.1
   
−
=Просмотр результатов=
  
−
==Сырой вывод==
  
 
<PRE>
  
<PRE>
  +
openssl x509 -noout -text -in /etc/k8s/kube-apiserver/certs/tls/kube-apiserver-tls.pem
−
cat k8s_pki_intermediate_ca_for_service_etcd_csr.json
  
 
</PRE>
  
</PRE>
−
{{#spoiler:show=CERTIFICATE REQUEST |
  
 
<PRE>
  
<PRE>
  +
Certificate:
−
{
  
  +
Data:
−
"request_id": "a58aadd1-d006-6de4-adf1-b0c3f7d4e02a",
  
  +
Version: 3 (0x2)
−
"lease_id": "",
  
  +
Serial Number:
−
"lease_duration": 0,
  
  +
71:a8:93:84:83:df:af:ba:78:df:63:3d:fe:4d:7f:f4:22:26:23:24
−
"renewable": false,
  
  +
Signature Algorithm: sha256WithRSAEncryption
−
"data": {
  
  +
Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-apiserver TLS
−
"csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIIC/DCCAeQCAQAwgbYxEDAOBgNVBAYTB1VrcmFpbmUxEDAOBgNVBAcTB0toYXJr\nb3YxJTAjBgNVBAkTHEx1aSBQYXN0ZXJhIHN0LiAzMjIgYXBwLiAxMzExDjAMBgNV\nBBETBTYxMTcyMSEwHwYDVQQKExhLOHMgVGhlIEhhcmRlc3QgV2F5IExhYnMxCzAJ\nBgNVBAsTAklUMSkwJwYDVQQDEyBJbnRlcm1lZGlhdGUgQ0EgZm9yIHNlcnZpY2Ug\nRVRDZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMPgSl8BYUCkDzdq\nMnJx89TlWirdsDv40sJcCIC/FKobMpdWlbBMDhmZeFkoPvDulmWIzMzpPF7+Q1Tb\npRxHnNkW83wsnnoxPTeR0ym+ixDeUl//NVsjOmH40W2fuQZ6j3S/DLfGGxdOFc5T\ns+akRHTTyD5nfIsMwgxDtMDSaf9oN9ugx8EqnQtBn5pQzap1E1b58R5JPhrJ+2ce\noH4NqXKbu4ZaWpzVH7RjTrf1AOpknCBjR9Zpxl+DjBch2qgJY0lnD373qaFKntGT\nDoZKRJeqCNBIYoB8o8KczFC46dSYTzBokwQQU4R9woAk+yMZI2v8I0EJCnFtsYF7\nnrkNuxcCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQAciGGKja/BVKEfe0qwvl7u\nitik2Evmp0pOFbxaajgEOztIms/a9GEanFM1HOLVlvehZWBjYUv/D5E1SNNfyIrV\nYCVvq0PViXB92el98sI9CYI7BkHQT8l7EMepehVgZbJ6pHzic7S4fxNB9Gcza10O\nFsuallqiCYndR2Ps/fOXbm40OAP+BndIuvjVcIRlXSIWTl910DORxysyP9otf3PG\ncW8kWMbAcHeMtlgPdS/ebG65WNzjSOws+ty9t4+wWMO6xI5rDTEhCdObsIJdhGaZ\nNPi9bcG017rJUwrNz7dHvpAFv0k+tsbJLmUaRwut+Gpk5Wr4pu4YAXhwuwwpdf64\n-----END CERTIFICATE REQUEST-----"
  
  +
Validity
−
},
  
  +
Not Before: Nov 14 08:59:08 2022 GMT
−
"warnings": null
  
  +
Not After : Nov 13 08:59:35 2027 GMT
−
}</PRE>
  
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-apiserver.az1.k8s.cluster.home
−
}}
  
  +
Subject Public Key Info:
  +
X509v3 extensions:
  +
X509v3 Key Usage: critical
  +
Digital Signature, Key Encipherment
  +
X509v3 Extended Key Usage:
  +
TLS Web Server Authentication
  +
X509v3 Subject Key Identifier:
  +
E0:69:16:9A:99:A8:E6:95:AB:2B:2D:BC:58:CF:5C:E0:61:BF:10:51
  +
X509v3 Authority Key Identifier:
  +
22:7D:70:47:DB:79:ED:91:79:B3:51:0E:23:5F:32:B9:37:01:8D:C1
  +
Authority Information Access:
  +
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/ca
  +
X509v3 Subject Alternative Name:
  +
DNS:kube-apiserver.az1.k8s.cluster.home, DNS:kube-apiserver.k8s.cluster.home, DNS:kubernetes, DNS:kubernetes.cluster.home, IP Address:10.0.12.1, IP Address:10.80.0.1, IP Address:127.0.0.1
  +
X509v3 CRL Distribution Points:
  +
Full Name:
  +
URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/crl
   
  +
</PRE>
−
==Сохранить запрос в файл==
  
  +
|-
−
* Проверить что вышло в более-менее читаемом формате (на первый взгляд выглядит корректно)
  
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
| <code>kube-apiserver</code>
  +
|| <code>--client-ca-file</code>
  +
|| <code>CA</code> <code>kube_apiserver_client_auth/</code>
  +
|| Не серверный<BR>Не клиентский<BR>'''CA'''
  +
|| Это СА который используется для проверки сертификатов, с которыми клиенты (другие сервисы или пользователи) подключаются к <code>kube-apiserver</code>. <BR>
  +
Важно, что ключ от этого сертификата в настройках <code>kube-apiserver</code> не участвует. <BR>Это означает что <code>kube-apiserver</code> может проверять сертификаты клиентов но не может выписывать новые сертификаты, эта часть - за администратором системы.
  +
  +
<BR>
  +
'''Именно с пмощью этого СА проверяются сертификаты как пользователей (если пользователи используют сертификаты) так и сервисов <code>kube-controller-manager</code>, <code>kube-proxy</code>, <code>kube-scheduler</code>, <code>kubelet</code>'''
  +
<BR>В случае PKI на основе <code>Vault</code> CA в любой момент можно скачать.
  +
||
 
<PRE>
  
<PRE>
  +
openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth.pem
−
cat k8s_pki_intermediate_ca_for_service_etcd_csr.json | jq -r .data.csr
  
 
</PRE>
  
</PRE>
 
<PRE>
  
<PRE>
  +
Certificate:
−
-----BEGIN CERTIFICATE REQUEST-----
  
  +
Data:
−
MIIC/DCCAeQCAQAwgbYxEDAOBgNVBAYTB1VrcmFpbmUxEDAOBgNVBAcTB0toYXJr
  
  +
Version: 3 (0x2)
−
b3YxJTAjBgNVBAkTHEx1aSBQYXN0ZXJhIHN0LiAzMjIgYXBwLiAxMzExDjAMBgNV
  
  +
Serial Number:
−
BBETBTYxMTcyMSEwHwYDVQQKExhLOHMgVGhlIEhhcmRlc3QgV2F5IExhYnMxCzAJ
  
  +
1a:ba:2f:66:84:5f:65:d4:cf:65:e2:d8:86:6a:a5:22:fd:57:8c:2b
−
BgNVBAsTAklUMSkwJwYDVQQDEyBJbnRlcm1lZGlhdGUgQ0EgZm9yIHNlcnZpY2Ug
  
  +
Signature Algorithm: sha256WithRSAEncryption
−
RVRDZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMPgSl8BYUCkDzdq
  
  +
Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
−
MnJx89TlWirdsDv40sJcCIC/FKobMpdWlbBMDhmZeFkoPvDulmWIzMzpPF7+Q1Tb
  
  +
Validity
−
pRxHnNkW83wsnnoxPTeR0ym+ixDeUl//NVsjOmH40W2fuQZ6j3S/DLfGGxdOFc5T
  
  +
Not Before: Nov 5 10:21:06 2022 GMT
−
s+akRHTTyD5nfIsMwgxDtMDSaf9oN9ugx8EqnQtBn5pQzap1E1b58R5JPhrJ+2ce
  
  +
Not After : Oct 31 10:21:36 2042 GMT
−
oH4NqXKbu4ZaWpzVH7RjTrf1AOpknCBjR9Zpxl+DjBch2qgJY0lnD373qaFKntGT
  
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, CN = Intermediate CA for service kube-apiserver CLIENT_AUTH
−
DoZKRJeqCNBIYoB8o8KczFC46dSYTzBokwQQU4R9woAk+yMZI2v8I0EJCnFtsYF7
  
  +
Subject Public Key Info:
−
nrkNuxcCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQAciGGKja/BVKEfe0qwvl7u
  
  +
X509v3 extensions:
−
itik2Evmp0pOFbxaajgEOztIms/a9GEanFM1HOLVlvehZWBjYUv/D5E1SNNfyIrV
  
  +
X509v3 Key Usage: critical
−
YCVvq0PViXB92el98sI9CYI7BkHQT8l7EMepehVgZbJ6pHzic7S4fxNB9Gcza10O
  
  +
Certificate Sign, CRL Sign
−
FsuallqiCYndR2Ps/fOXbm40OAP+BndIuvjVcIRlXSIWTl910DORxysyP9otf3PG
  
  +
X509v3 Basic Constraints: critical
−
cW8kWMbAcHeMtlgPdS/ebG65WNzjSOws+ty9t4+wWMO6xI5rDTEhCdObsIJdhGaZ
  
  +
CA:TRUE
−
NPi9bcG017rJUwrNz7dHvpAFv0k+tsbJLmUaRwut+Gpk5Wr4pu4YAXhwuwwpdf64
  
  +
X509v3 Subject Key Identifier:
−
-----END CERTIFICATE REQUEST-----
  
  +
2F:8E:7A:14:33:0D:E1:66:69:81:85:F5:C5:EC:09:3E:89:E1:B7:DF
  +
X509v3 Authority Key Identifier:
  +
02:F8:85:2B:75:F8:E1:1C:69:28:30:32:21:2D:86:71:AF:AB:EC:3C
  +
Authority Information Access:
  +
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_root_ca/ca
  +
X509v3 CRL Distribution Points:
  +
Full Name:
  +
URI:http://vault.home:8200/v1/k8s_pki_root_ca/crl
 
</PRE>
  
</PRE>
  +
|-
−
Сохранить в файл только нужную часть:
  
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
| <code>kube-apiserver</code>
  +
|| <code>--kubelet-certificate-authority</code>
  +
|| <code>CA</code><BR><code>kubelet_tls</code>
  +
|| Не серверный<BR>Не клиентский<BR>'''CA'''
  +
|| Это <code>CA</code> используется для того, что бы проверить сертификат <code>kubelet</code>, и быть уверенным что подключение к правильному <code>kubelet</code><br>
  +
Этим же СА подписываются сертификаты <code>kubelet</code> для TLS <BR> (конфигурация <code>kubelet</code>)
  +
<code>/etc/k8s/kubelet/kubelet-config.yaml</code>
 
<PRE>
  
<PRE>
  +
tlsCertFile: "/etc/k8s/kubelet/certs/tls/kubelet-tls.pem"
−
cat k8s_pki_intermediate_ca_for_service_etcd_csr.json | jq -r .data.csr > k8s_pki_intermediate_ca_for_service_etcd.csr
  
  +
tlsPrivateKeyFile: "/etc/k8s/kubelet/certs/tls/kubelet-tls.key"
 
</PRE>
  
</PRE>
  +
||
−
* Проверить более подробно
 
 
<PRE>
  
<PRE>
  +
openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kubelet_tls.pem
−
openssl req -in k8s_pki_intermediate_ca_for_service_etcd.csr -text
  
 
</PRE>
  
</PRE>
−
{{#spoiler:show=Результат проверки в человекочитаемом виде|
  
 
<PRE>
  
<PRE>
−
Certificate Request:
 +
Certificate:
 
Data:
  
Data:
−
Version: 1 (0x0)
 +
Version: 3 (0x2)
  +
Serial Number:
−
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, postalCode = 61172, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service ETCd
  
  +
33:04:63:a1:86:f2:80:bd:96:5e:10:46:ae:d5:c8:28:89:d0:74:34
  +
Signature Algorithm: sha256WithRSAEncryption
  +
Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
  +
Validity
  +
Not Before: Nov 10 14:11:32 2022 GMT
  +
Not After : Nov 5 14:12:02 2042 GMT
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kubelet TLS
 
Subject Public Key Info:
  
Subject Public Key Info:
 
Public Key Algorithm: rsaEncryption
  
Public Key Algorithm: rsaEncryption
−
RSA Public-Key: (2048 bit)
 +
Public-Key: (2048 bit)
 
Modulus:
  
Modulus:
−
00:c3:e0:4a:5f:01:61:40:a4:0f:37:6a:32:72:71:
  
−
f3:d4:e5:5a:2a:dd:b0:3b:f8:d2:c2:5c:08:80:bf:
  
−
14:aa:1b:32:97:56:95:b0:4c:0e:19:99:78:59:28:
  
−
3e:f0:ee:96:65:88:cc:cc:e9:3c:5e:fe:43:54:db:
  
−
a5:1c:47:9c:d9:16:f3:7c:2c:9e:7a:31:3d:37:91:
  
−
d3:29:be:8b:10:de:52:5f:ff:35:5b:23:3a:61:f8:
  
−
d1:6d:9f:b9:06:7a:8f:74:bf:0c:b7:c6:1b:17:4e:
  
−
15:ce:53:b3:e6:a4:44:74:d3:c8:3e:67:7c:8b:0c:
  
−
c2:0c:43:b4:c0:d2:69:ff:68:37:db:a0:c7:c1:2a:
  
−
9d:0b:41:9f:9a:50:cd:aa:75:13:56:f9:f1:1e:49:
  
−
3e:1a:c9:fb:67:1e:a0:7e:0d:a9:72:9b:bb:86:5a:
  
−
5a:9c:d5:1f:b4:63:4e:b7:f5:00:ea:64:9c:20:63:
  
−
47:d6:69:c6:5f:83:8c:17:21:da:a8:09:63:49:67:
  
−
0f:7e:f7:a9:a1:4a:9e:d1:93:0e:86:4a:44:97:aa:
  
−
08:d0:48:62:80:7c:a3:c2:9c:cc:50:b8:e9:d4:98:
  
−
4f:30:68:93:04:10:53:84:7d:c2:80:24:fb:23:19:
  
−
23:6b:fc:23:41:09:0a:71:6d:b1:81:7b:9e:b9:0d:
  
−
bb:17
  
 
Exponent: 65537 (0x10001)
  
Exponent: 65537 (0x10001)
−
Attributes:
 +
X509v3 extensions:
−
a0:00
 +
X509v3 Key Usage: critical
  +
Certificate Sign, CRL Sign
−
Signature Algorithm: sha256WithRSAEncryption
  
  +
X509v3 Basic Constraints: critical
−
1c:88:61:8a:8d:af:c1:54:a1:1f:7b:4a:b0:be:5e:ee:8a:d8:
  
  +
CA:TRUE
−
a4:d8:4b:e6:a7:4a:4e:15:bc:5a:6a:38:04:3b:3b:48:9a:cf:
  
  +
X509v3 Subject Key Identifier:
−
da:f4:61:1a:9c:53:35:1c:e2:d5:96:f7:a1:65:60:63:61:4b:
  
−
ff:0f:91:35:48:d3:5f:c8:8a:d5:60:25:6f:ab:43:d5:89:70:
 +
F1:9C:3B:FB:01:4E:9A:3F:F5:E8:28:CE:99:60:9F:E3:5E:51:DA:C8
  +
X509v3 Authority Key Identifier:
−
7d:d9:e9:7d:f2:c2:3d:09:82:3b:06:41:d0:4f:c9:7b:10:c7:
  
−
a9:7a:15:60:65:b2:7a:a4:7c:e2:73:b4:b8:7f:13:41:f4:67:
 +
02:F8:85:2B:75:F8:E1:1C:69:28:30:32:21:2D:86:71:AF:AB:EC:3C
  +
Authority Information Access:
−
33:6b:5d:0e:16:cb:9a:96:5a:a2:09:89:dd:47:63:ec:fd:f3:
  
  +
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_root_ca/ca
−
97:6e:6e:34:38:03:fe:06:77:48:ba:f8:d5:70:84:65:5d:22:
  
  +
X509v3 CRL Distribution Points:
−
16:4e:5f:75:d0:33:91:c7:2b:32:3f:da:2d:7f:73:c6:71:6f:
  
  +
Full Name:
−
24:58:c6:c0:70:77:8c:b6:58:0f:75:2f:de:6c:6e:b9:58:dc:
  
  +
URI:http://vault.home:8200/v1/k8s_pki_root_ca/crl
−
e3:48:ec:2c:fa:dc:bd:b7:8f:b0:58:c3:ba:c4:8e:6b:0d:31:
  
−
21:09:d3:9b:b0:82:5d:84:66:99:34:f8:bd:6d:c1:b4:d7:ba:
  
−
c9:53:0a:cd:cf:b7:47:be:90:05:bf:49:3e:b6:c6:c9:2e:65:
  
−
1a:47:0b:ad:f8:6a:64:e5:6a:f8:a6:ee:18:01:78:70:bb:0c:
  
−
29:75:fe:b8
  
−
-----BEGIN CERTIFICATE REQUEST-----
  
−
MIIC/DCCAeQCAQAwgbYxEDAOBgNVBAYTB1VrcmFpbmUxEDAOBgNVBAcTB0toYXJr
  
−
b3YxJTAjBgNVBAkTHEx1aSBQYXN0ZXJhIHN0LiAzMjIgYXBwLiAxMzExDjAMBgNV
  
−
BBETBTYxMTcyMSEwHwYDVQQKExhLOHMgVGhlIEhhcmRlc3QgV2F5IExhYnMxCzAJ
  
−
BgNVBAsTAklUMSkwJwYDVQQDEyBJbnRlcm1lZGlhdGUgQ0EgZm9yIHNlcnZpY2Ug
  
−
RVRDZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMPgSl8BYUCkDzdq
  
−
MnJx89TlWirdsDv40sJcCIC/FKobMpdWlbBMDhmZeFkoPvDulmWIzMzpPF7+Q1Tb
  
−
pRxHnNkW83wsnnoxPTeR0ym+ixDeUl//NVsjOmH40W2fuQZ6j3S/DLfGGxdOFc5T
  
−
s+akRHTTyD5nfIsMwgxDtMDSaf9oN9ugx8EqnQtBn5pQzap1E1b58R5JPhrJ+2ce
  
−
oH4NqXKbu4ZaWpzVH7RjTrf1AOpknCBjR9Zpxl+DjBch2qgJY0lnD373qaFKntGT
  
−
DoZKRJeqCNBIYoB8o8KczFC46dSYTzBokwQQU4R9woAk+yMZI2v8I0EJCnFtsYF7
  
−
nrkNuxcCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQAciGGKja/BVKEfe0qwvl7u
  
−
itik2Evmp0pOFbxaajgEOztIms/a9GEanFM1HOLVlvehZWBjYUv/D5E1SNNfyIrV
  
−
YCVvq0PViXB92el98sI9CYI7BkHQT8l7EMepehVgZbJ6pHzic7S4fxNB9Gcza10O
  
−
FsuallqiCYndR2Ps/fOXbm40OAP+BndIuvjVcIRlXSIWTl910DORxysyP9otf3PG
  
−
cW8kWMbAcHeMtlgPdS/ebG65WNzjSOws+ty9t4+wWMO6xI5rDTEhCdObsIJdhGaZ
  
−
NPi9bcG017rJUwrNz7dHvpAFv0k+tsbJLmUaRwut+Gpk5Wr4pu4YAXhwuwwpdf64
  
−
-----END CERTIFICATE REQUEST-----
  
 
</PRE>
  
</PRE>
  +
|-
−
}}
  
   
−
=Генерация сертификата по запросу=
  
−
* <B>@ k8s_pki_intermediate_ca_for_service_etcd.csr</B> - имя файла (с префиксом @) в котором сохранен запрос на создание сертификата с предыдущего шага
  
   
  +
−
=Создание сертефиката CA на основании запроса=
  
  +
  +
  +
| <code>kube-apiserver</code>
  +
|| <code>--kubelet-client-certificate</code> <br> <code>--kubelet-client-key</code>
  +
|| <code>kubelet_client_auth/</code>
  +
|| Клиентский <br>TLS Web Clien<br>Authentication
  +
|| Это сертификат используется <code>kube-apiserver</code> что бы авторизоваться у <code>kubelet</code><br>, это нужно что бы <code>kubelet</code> мог быть уверен что к нему пришел доверенный <code>kube-apiserver</code>
  +
||
  +
Обратить внимание на <code>CN = kube-apiserver-to-kubelet</code> - для этого пользователя потребуется создать отдельный <code>ClusterRoleBinding</code>, по-умолчанию его нет. Естественно, что для своих ролей имена можно использовать любые, <code>kube-apiserver-to-kubelet</code> это текстовый идентификатор, который можно назначить по своему усмотрению, но, одинаковый как в сертификате так и в <code>ClusterRoleBinding</code>
 
<PRE>
  
<PRE>
  +
openssl x509 -noout -text -in /etc/k8s/kube-apiserver/certs/client_auth/kubelet-client_auth.pem
−
vault \
  
−
write \
  
−
-format=json \
  
−
k8s_pki_root_ca/root/sign-intermediate \
  
−
csr=@k8s_pki_intermediate_ca_for_service_etcd.csr \
  
−
country="Ukraine" \
  
−
locality="Kharkov" \
  
−
street_address="Lui Pastera st. 322 app. 131" \
  
−
postal_code="61172" \
  
−
organization="K8s The Hardest Way Labs" \
  
−
ou="IT" \
  
−
format=pem_bundle \
  
−
ttl="175200h" > k8s_pki_intermediate_ca_for_service_etcd_pem_bundle.json
  
 
</PRE>
  
</PRE>
−
=="Сырой" результат==
  
 
<PRE>
  
<PRE>
  +
Certificate:
−
cat k8s_pki_intermediate_ca_for_service_etcd_pem_bundle.json
  
  +
Data:
  +
Version: 3 (0x2)
  +
Serial Number:
  +
28:07:04:c7:ce:4a:6e:29:fc:f7:c9:60:00:57:2a:9c:16:ca:53:8f
  +
Signature Algorithm: sha256WithRSAEncryption
  +
Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, CN = Intermediate CA for service kubelet CLIENT_AUTH
  +
Validity
  +
Not Before: Nov 13 14:43:03 2022 GMT
  +
Not After : Nov 12 14:43:31 2027 GMT
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:masters, OU = system, CN = kube-apiserver-to-kubelet
  +
Subject Public Key Info:
  +
Public Key Algorithm: rsaEncryption
  +
Public-Key: (2048 bit)
  +
Modulus:
  +
Exponent: 65537 (0x10001)
  +
X509v3 extensions:
  +
X509v3 Key Usage: critical
  +
Digital Signature, Key Encipherment
  +
X509v3 Extended Key Usage:
  +
TLS Web Client Authentication
  +
X509v3 Subject Key Identifier:
  +
22:7C:92:2B:A3:5F:53:0F:B5:7A:F2:84:FA:55:C9:51:DD:33:78:E8
  +
X509v3 Authority Key Identifier:
  +
50:35:A5:C5:B4:C6:FC:65:04:08:76:F7:FB:56:D3:76:6D:96:36:2F
  +
Authority Information Access:
  +
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kubelet_client_auth/ca
  +
X509v3 Subject Alternative Name:
  +
DNS:kube-apiserver-to-kubelet
  +
X509v3 CRL Distribution Points:
  +
Full Name:
  +
URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kubelet_client_auth/crl
 
</PRE>
  
</PRE>
  +
|-
−
{{#spoiler:show=Результат в "сыром виде"|
  
  +
|}
  +
  +
==<code>kube-controller-manager</code>==
  +
  +
{| class="wikitable sortable"
  +
|+ Сертификаты K8s <code>kube-controller-manager</code>
  +
|-
  +
! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Тип сертификата (серверный/клиентский/CA) !! Назначение !! Subject и подробности
  +
|-
  +
  +
| <code>kube-controller-manager</code>
  +
||
  +
<code>--tls-cert-file</code><BR>
  +
<code>--tls-private-key-file</code>
  +
||<code>kube_controller_manager_tls/</code>
  +
|| Серверный<BR>TLS Web Server<BR>Authentication
  +
||<code>kube-controller-manager</code> имеет свой API (по умолчанию - на порту 10257), в котором есть как минимум такие endpoints: /healthz, /readyz, /livez, /metrics.<BR>
  +
Этот сертификат служит для организации <code>TLS/HTTPS</code> для этого API
  +
<br>
  +
<br>
  +
Для разрешения доступа без авторизации служит параметр <code>--authorization-always-allow-paths=/healthz,/readyz,/livez,/metrics<code>, где перечислаются endpoints к которым можно получить доступ.
  +
|| Получить этот сертификат можно непосредственно подключившись к порту
 
<PRE>
  
<PRE>
  +
openssl s_client -connect kube-controller-manager.az1.k8s.cluster.home:10257
−
{
  
−
"request_id": "fbf7b67a-4301-86d0-4d3c-08f227ef8e9f",
  
−
"lease_id": "",
  
−
"lease_duration": 0,
  
−
"renewable": false,
  
−
"data": {
  
−
"certificate": "-----BEGIN CERTIFICATE-----\nMIIE9TCCA92gAwIBAgIUT+T1Nm5/8WjEJmyXwSG7RlRtmJMwDQYJKoZIhvcNAQEL\nBQAwgcAxEDAOBgNVBAYTB1VrcmFpbmUxEDAOBgNVBAcTB0toYXJrb3YxLTAPBgNV\nBAkTCGFwcC4gMTMxMBoGA1UECRMTTHVpIFBhc3RlcmEgU3QuIDMyMjEOMAwGA1UE\nERMFNjExNzIxFTATBgNVBAoTDEhvbWUgTmV0d29yazELMAkGA1UECxMCSVQxNzA1\nBgNVBAMTLlJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IGZvciBIb21lIE5ldHdv\ncmsgdjIwHhcNMjIxMDAyMTYxNjU1WhcNNDIwOTI3MTYxNzI1WjCBtjEQMA4GA1UE\nBhMHVWtyYWluZTEQMA4GA1UEBxMHS2hhcmtvdjElMCMGA1UECRMcTHVpIFBhc3Rl\ncmEgc3QuIDMyMiBhcHAuIDEzMTEOMAwGA1UEERMFNjExNzIxITAfBgNVBAoTGEs4\ncyBUaGUgSGFyZGVzdCBXYXkgTGFiczELMAkGA1UECxMCSVQxKTAnBgNVBAMTIElu\ndGVybWVkaWF0ZSBDQSBmb3Igc2VydmljZSBFVENkMIIBIjANBgkqhkiG9w0BAQEF\nAAOCAQ8AMIIBCgKCAQEAw+BKXwFhQKQPN2oycnHz1OVaKt2wO/jSwlwIgL8Uqhsy\nl1aVsEwOGZl4WSg+8O6WZYjMzOk8Xv5DVNulHEec2RbzfCyeejE9N5HTKb6LEN5S\nX/81WyM6YfjRbZ+5BnqPdL8Mt8YbF04VzlOz5qREdNPIPmd8iwzCDEO0wNJp/2g3\n26DHwSqdC0GfmlDNqnUTVvnxHkk+Gsn7Zx6gfg2pcpu7hlpanNUftGNOt/UA6mSc\nIGNH1mnGX4OMFyHaqAljSWcPfvepoUqe0ZMOhkpEl6oI0EhigHyjwpzMULjp1JhP\nMGiTBBBThH3CgCT7Ixkja/wjQQkKcW2xgXueuQ27FwIDAQABo4HuMIHrMA4GA1Ud\nDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRAf2zV00Ozzw9c\nludrrD8ZTYtJNDAfBgNVHSMEGDAWgBQC+IUrdfjhHGkoMDIhLYZxr6vsPDBIBggr\nBgEFBQcBAQQ8MDowOAYIKwYBBQUHMAKGLGh0dHA6Ly92YXVsdC5ob21lOjgyMDAv\ndjEvazhzX3BraV9yb290X2NhL2NhMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly92\nYXVsdC5ob21lOjgyMDAvdjEvazhzX3BraV9yb290X2NhL2NybDANBgkqhkiG9w0B\nAQsFAAOCAQEAAGRmGgzdHM5w00Xos03Be0jat24CSQskVCAHFhV9dJN7v4YVuZUG\nHVsb2m0MQmw5b3WGo2J9lNqIO0ETgnzqvye+Zj3DcetYaHZ300Rpv5QFqQNdebQY\nO8MP03NvqPrlsscGmjWQ8swKRKIBjsIgVlQuWMK/30k5QXEX9Nys/p3gl+OfK6MA\nnhKE6vYOneNpXTHJOly/0boyNf+/+MkFgFeLbe/gxNgyJu8CVYfaGjQ4FQNqDoy3\nlMdepwKstmOo05m3/6qs6jEfVVjSf90hMbBbdelzpe3/ectYEc5ZqRdqNfeo5luR\nMYmvkBormMQyOa3qsXCOjcyxQZ4hvXIVJA==\n-----END CERTIFICATE-----",
  
−
"expiration": 2295447445,
  
−
"issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIEdTCCA12gAwIBAgIUbJDrkNRfhm3Y+/j4oE0H+JkeYgIwDQYJKoZIhvcNAQEL\nBQAwgcAxEDAOBgNVBAYTB1VrcmFpbmUxEDAOBgNVBAcTB0toYXJrb3YxLTAPBgNV\nBAkTCGFwcC4gMTMxMBoGA1UECRMTTHVpIFBhc3RlcmEgU3QuIDMyMjEOMAwGA1UE\nERMFNjExNzIxFTATBgNVBAoTDEhvbWUgTmV0d29yazELMAkGA1UECxMCSVQxNzA1\nBgNVBAMTLlJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IGZvciBIb21lIE5ldHdv\ncmsgdjIwIBcNMjIxMDAyMTQ1NjMyWhgPMjA1MjA5MjQxNDU3MDBaMIHAMRAwDgYD\nVQQGEwdVa3JhaW5lMRAwDgYDVQQHEwdLaGFya292MS0wDwYDVQQJEwhhcHAuIDEz\nMTAaBgNVBAkTE0x1aSBQYXN0ZXJhIFN0LiAzMjIxDjAMBgNVBBETBTYxMTcyMRUw\nEwYDVQQKEwxIb21lIE5ldHdvcmsxCzAJBgNVBAsTAklUMTcwNQYDVQQDEy5Sb290\nIENlcnRpZmljYXRlIEF1dGhvcml0eSBmb3IgSG9tZSBOZXR3b3JrIHYyMIIBIjAN\nBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx299heF9ca7N4qaFLTaFxDEiyLwR\nHMW9EOxodl0W4f62AN5PxCNI1CqXhGSIgCO9Yzy6QLdm9m8PtbcQiITYbhkInKBU\ne7ruwoiZYfvpQyJhvQH+8rAzVjtRrWNXuQDPYTiYEpTycbM5mrDR3yBeOT85/bxH\nkgJ+g8V7mpgstA9IbDNZDEmg5eco0Hgwn/LC4RM815x+mJV3QDb2mNcFIck1/t58\nF8T0GQ+OothQfOwC7tC+1qvlJjb35RP+Q3CRaJ5G3dFTDqTb0h8xY4B65wceOnnk\nOH7uwWCGpHwm0/KHyfI79sGvMz7S+mJeR8rxK5NFSzBHmHv4zaIZ54rEZwIDAQAB\no2MwYTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU\nAviFK3X44RxpKDAyIS2Gca+r7DwwHwYDVR0jBBgwFoAUAviFK3X44RxpKDAyIS2G\nca+r7DwwDQYJKoZIhvcNAQELBQADggEBAKYfcKf2Pgpc7BH3pN/axbtCw1oU8q4p\n5/KkyT6Q5XVxSvkO6GRn1V+uouofFhuriudbyB0eQo7X5z2+AuE3+juz3w/YGUFJ\nU/fGt+1WemBuxf3qtPdD6HtyHLF6SnCTh1OlZpILiXPNF6zHMXq4fRRVyEVWmkB0\nObRXEq0z5Fq0NHVU9cyxP67h99V6+N3ILNskEGmDqGwCtDyr7xesd638qN7xOTQo\n+2M0eqCV6nOdw6Z1xGmVK91kqEYEbFMgGLBCq53An7Fg/H44ytiztJqKIgxt/zY2\nPWuXBPK0nssQ5D87CWL1VDQIIVHYLS8xPQ1APWTF5M53u4h6t9mrM/U=\n-----END CERTIFICATE-----",
  
−
"serial_number": "4f:e4:f5:36:6e:7f:f1:68:c4:26:6c:97:c1:21:bb:46:54:6d:98:93"
  
−
},
  
−
"warnings": null
  
−
}
  
 
</PRE>
  
</PRE>
  +
<PRE>
−
}}
  
  +
subject=C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-controller-manager.az1.k8s.cluster.home
  +
issuer=C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-controller-manager TLS
  +
</PRE>
  +
Или в соответствующем файле (путь - в конфиге сервиса)
  +
<PRE>
  +
openssl x509 -noout -text -in kube-controller-manager-tls.pem
  +
</PRE>
  +
Certificate:
  +
Data:
  +
Version: 3 (0x2)
  +
Serial Number:
  +
68:35:c6:9e:d5:7d:c6:c8:ff:64:03:e7:fd:d8:c0:03:ff:ee:ec:50
  +
Signature Algorithm: sha256WithRSAEncryption
  +
Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-controller-manager TLS
  +
Validity
  +
Not Before: Nov 10 17:18:43 2022 GMT
  +
Not After : Nov 9 17:19:11 2027 GMT
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-controller-manager.az1.k8s.cluster.home
  +
Subject Public Key Info:
  +
Public Key Algorithm: rsaEncryption
  +
Public-Key: (2048 bit)
  +
Modulus:
  +
...
  +
Exponent: 65537 (0x10001)
  +
X509v3 extensions:
  +
X509v3 Key Usage: critical
  +
Digital Signature, Key Encipherment
  +
X509v3 Extended Key Usage:
  +
TLS Web Server Authentication
  +
X509v3 Subject Key Identifier:
  +
7A:16:23:C5:0F:42:C2:D2:F2:FD:4C:2F:98:88:62:4D:C7:C6:E0:2A
  +
X509v3 Authority Key Identifier:
  +
3A:B0:CE:B4:3E:05:3F:7C:5F:87:24:BA:89:99:03:C6:9F:4C:2E:B1
  +
Authority Information Access:
  +
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/ca
  +
X509v3 Subject Alternative Name:
  +
DNS:kube-controller-manager.az1.k8s.cluster.home, DNS:kube-controller-manager.k8s.cluster.home, IP Address:10.0.12.1
  +
X509v3 CRL Distribution Points:
  +
Full Name:
  +
URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/crl
  +
Signature Algorithm: sha256WithRSAEncryption
  +
Signature Value:
  +
...
  +
</PRE>
  +
|-
   
  +
−
==PEM Файл==
  
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
| <code>kube-controller-manager</code>
  +
|| --root-ca-file
  +
||Root СА
  +
||Не Серверный<BR>Не Клиентский<BR>'''CA'''
  +
||Этот СА которым подписаны сертификаты для <code>HTTPS/TLS</code> для <code>kube-api-server</code> и он используется для проверки серверных сертификатов. Обладая этим CA можно проверить что подключение происходит к правильному <code>kube-apiserver</code>
  +
||
 
<PRE>
  
<PRE>
  +
openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem
−
cat k8s_pki_intermediate_ca_for_service_etcd_pem_bundle.json | jq -r .data.certificate > k8s_pki_intermediate_ca_for_service_etcd_certificate.pem
  
 
</PRE>
  
</PRE>
 
<PRE>
  
<PRE>
  +
Certificate:
−
-----BEGIN CERTIFICATE-----
  
  +
Data:
−
MIIE9TCCA92gAwIBAgIUT+T1Nm5/8WjEJmyXwSG7RlRtmJMwDQYJKoZIhvcNAQEL
  
  +
Version: 3 (0x2)
−
BQAwgcAxEDAOBgNVBAYTB1VrcmFpbmUxEDAOBgNVBAcTB0toYXJrb3YxLTAPBgNV
  
  +
Serial Number:
−
BAkTCGFwcC4gMTMxMBoGA1UECRMTTHVpIFBhc3RlcmEgU3QuIDMyMjEOMAwGA1UE
  
  +
0c:8b:42:a7:b4:5a:56:0e:b6:72:d0:40:03:70:5c:19:49:03:43:90
−
ERMFNjExNzIxFTATBgNVBAoTDEhvbWUgTmV0d29yazELMAkGA1UECxMCSVQxNzA1
  
  +
Signature Algorithm: sha256WithRSAEncryption
−
BgNVBAMTLlJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IGZvciBIb21lIE5ldHdv
  
  +
Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
−
cmsgdjIwHhcNMjIxMDAyMTYxNjU1WhcNNDIwOTI3MTYxNzI1WjCBtjEQMA4GA1UE
  
  +
Validity
−
BhMHVWtyYWluZTEQMA4GA1UEBxMHS2hhcmtvdjElMCMGA1UECRMcTHVpIFBhc3Rl
  
  +
Not Before: Nov 10 14:09:38 2022 GMT
−
cmEgc3QuIDMyMiBhcHAuIDEzMTEOMAwGA1UEERMFNjExNzIxITAfBgNVBAoTGEs4
  
  +
Not After : Nov 5 14:10:08 2042 GMT
−
cyBUaGUgSGFyZGVzdCBXYXkgTGFiczELMAkGA1UECxMCSVQxKTAnBgNVBAMTIElu
  
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-apiserver TLS
−
dGVybWVkaWF0ZSBDQSBmb3Igc2VydmljZSBFVENkMIIBIjANBgkqhkiG9w0BAQEF
  
−
AAOCAQ8AMIIBCgKCAQEAw+BKXwFhQKQPN2oycnHz1OVaKt2wO/jSwlwIgL8Uqhsy
  
−
l1aVsEwOGZl4WSg+8O6WZYjMzOk8Xv5DVNulHEec2RbzfCyeejE9N5HTKb6LEN5S
  
−
X/81WyM6YfjRbZ+5BnqPdL8Mt8YbF04VzlOz5qREdNPIPmd8iwzCDEO0wNJp/2g3
  
−
26DHwSqdC0GfmlDNqnUTVvnxHkk+Gsn7Zx6gfg2pcpu7hlpanNUftGNOt/UA6mSc
  
−
IGNH1mnGX4OMFyHaqAljSWcPfvepoUqe0ZMOhkpEl6oI0EhigHyjwpzMULjp1JhP
  
−
MGiTBBBThH3CgCT7Ixkja/wjQQkKcW2xgXueuQ27FwIDAQABo4HuMIHrMA4GA1Ud
  
−
DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRAf2zV00Ozzw9c
  
−
ludrrD8ZTYtJNDAfBgNVHSMEGDAWgBQC+IUrdfjhHGkoMDIhLYZxr6vsPDBIBggr
  
−
BgEFBQcBAQQ8MDowOAYIKwYBBQUHMAKGLGh0dHA6Ly92YXVsdC5ob21lOjgyMDAv
  
−
djEvazhzX3BraV9yb290X2NhL2NhMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly92
  
−
YXVsdC5ob21lOjgyMDAvdjEvazhzX3BraV9yb290X2NhL2NybDANBgkqhkiG9w0B
  
−
AQsFAAOCAQEAAGRmGgzdHM5w00Xos03Be0jat24CSQskVCAHFhV9dJN7v4YVuZUG
  
−
HVsb2m0MQmw5b3WGo2J9lNqIO0ETgnzqvye+Zj3DcetYaHZ300Rpv5QFqQNdebQY
  
−
O8MP03NvqPrlsscGmjWQ8swKRKIBjsIgVlQuWMK/30k5QXEX9Nys/p3gl+OfK6MA
  
−
nhKE6vYOneNpXTHJOly/0boyNf+/+MkFgFeLbe/gxNgyJu8CVYfaGjQ4FQNqDoy3
  
−
lMdepwKstmOo05m3/6qs6jEfVVjSf90hMbBbdelzpe3/ectYEc5ZqRdqNfeo5luR
  
−
MYmvkBormMQyOa3qsXCOjcyxQZ4hvXIVJA==
  
−
-----END CERTIFICATE-----
  
 
</PRE>
  
</PRE>
   
  +
|-
−
==Детали сертефиката==
  
  +
  +
  +
|}
  +
  +
==<code>kube-proxy</code>==
  +
Для <code>kube-proxy</code> за исключением <code>kubeconfig</code> сертификаты не используются
  +
  +
==<code>kube-scheduler</code>==
  +
  +
{| class="wikitable sortable"
  +
|+ Сертификаты K8s <code>kube-scheduler</code>
  +
|-
  +
! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Тип сертификата (серверный/клиентский/CA) !! Назначение !! Subject и подробности
  +
  +
|-
  +
| <code>kube-scheduler</code>
  +
||<code>--tls-cert-file</code> <br> <code>--tls-private-key-file</code>
  +
||<code>kube_scheduler_tls</code>
  +
||Серверный<BR>TLS Web Server<BR>Authentication
  +
||
  +
<code>kube-scheduler</code> имеет свой API (по умолчанию - на порту 10259), в котором есть как минимум такие endpoints: /healthz, /readyz, /livez, /metrics.
  +
Этот сертификат служит для организации <code>TLS/HTTPS</code> для этого API<br><br>
  +
Для разрешения доступа без авторизации служит параметр <code>--authorization-always-allow-paths=/healthz,/readyz,/livez,/metrics<code>, где перечислаются endpoints к которым можно получить доступ.
  +
||
  +
Сертификат можно просмотреть:
  +
  +
<PRE> openssl s_client -connect kube-scheduler.az1.k8s.cluster.home:10259</PRE>
 
<PRE>
  
<PRE>
  +
subject=C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-scheduler.az1.k8s.cluster.home
−
openssl x509 -in k8s_pki_intermediate_ca_for_service_etcd_certificate.pem -noout -text
  
  +
issuer=C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-scheduler TLS
  +
</PRE>
  +
Или посмотреть в файле (путь к файлу в параметрах сервиса)
  +
<PRE>openssl x509 -noout -text -in kube-scheduler-tls.pem
 
</PRE>
  
</PRE>
 
<PRE>
  
<PRE>
Строка 260: Строка 649:
 
Version: 3 (0x2)
  
Version: 3 (0x2)
 
Serial Number:
  
Serial Number:
−
4f:e4:f5:36:6e:7f:f1:68:c4:26:6c:97:c1:21:bb:46:54:6d:98:93
 +
69:35:40:e1:3d:40:4f:f4:f4:0e:a7:a8:6b:cf:ab:5e:78:fd:76:e4
  +
Signature Algorithm: sha256WithRSAEncryption
  +
Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-scheduler TLS
  +
Validity
  +
Not Before: Nov 10 17:43:55 2022 GMT
  +
Not After : Nov 9 17:44:24 2027 GMT
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-scheduler.az1.k8s.cluster.home
  +
Subject Public Key Info:
  +
Public Key Algorithm: rsaEncryption
  +
Public-Key: (2048 bit)
  +
Modulus:
  +
...
  +
Exponent: 65537 (0x10001)
  +
X509v3 extensions:
  +
X509v3 Key Usage: critical
  +
Digital Signature, Key Encipherment
  +
X509v3 Extended Key Usage:
  +
TLS Web Server Authentication
  +
X509v3 Subject Key Identifier:
  +
1E:54:7A:95:6C:DF:B4:99:1E:52:AC:33:42:E4:F0:FC:0C:64:55:A0
  +
X509v3 Authority Key Identifier:
  +
89:20:99:22:3A:5F:FB:50:26:01:42:BD:36:B6:F6:F3:B7:E4:51:A9
  +
Authority Information Access:
  +
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/ca
  +
X509v3 Subject Alternative Name:
  +
DNS:kube-scheduler.az1.k8s.cluster.home, DNS:kube-scheduler.k8s.cluster.home, IP Address:10.0.12.1
  +
X509v3 CRL Distribution Points:
  +
Full Name:
  +
URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/crl
  +
Signature Algorithm: sha256WithRSAEncryption
  +
Signature Value:
  +
...
  +
</PRE>
  +
|-
  +
|}
  +
  +
==<code>kubelet</code>==
  +
Для <code>kubelet</code> сертификаты указываются в файле, определенном в параметре <code>--config=/etc/k8s/kubelet/kubelet-config.yaml</code>
  +
<PRE>
  +
kind: KubeletConfiguration
  +
apiVersion: kubelet.config.k8s.io/v1beta1
  +
authentication:
  +
anonymous:
  +
enabled: false
  +
webhook:
  +
enabled: true
  +
x509:
  +
clientCAFile: "/etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kubelet_client_auth.pem"
  +
authorization:
  +
mode: Webhook
  +
clusterDomain: "cluster.home"
  +
clusterDNS:
  +
- "10.80.0.10"
  +
resolvConf: "/run/systemd/resolve/resolv.conf"
  +
runtimeRequestTimeout: "15m"
  +
tlsCertFile: "/etc/k8s/kubelet/certs/tls/kubelet-tls.pem"
  +
tlsPrivateKeyFile: "/etc/k8s/kubelet/certs/tls/kubelet-tls.key"
  +
authorizationMode: Node,RBAC
  +
</PRE>
  +
  +
  +
  +
  +
{| class="wikitable sortable"
  +
|+ Сертификаты K8s <code>kubelet</code>
  +
|-
  +
! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Тип сертификата (серверный/клиентский/CA) !! Назначение !! Subject и подробности
  +
  +
|-
  +
| <code>kubelet</code>
  +
||<code>clientCAFile</code>
  +
||Root CA (другими словами этот СА подписан корневым СА, а сам является промежуточным СА)
  +
|| Не серверный<BR>Не клиентский<BR>'''СА'''
  +
|| Предназначен для проверки сертификатов с которыми подключаются клиенты (насколько я знаю это только <code>kube-apiserver</code>, в его параметрах это <code>--kubelet-client-certificate</code> и
  +
<code>--kubelet-client-key</code>.
  +
||
  +
  +
Сертификат можно просмотреть:
  +
<PRE>
  +
openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kubelet_client_auth.pem
  +
</PRE>
  +
<PRE>
  +
Certificate:
  +
Data:
  +
Version: 3 (0x2)
  +
Serial Number:
  +
6e:c2:5c:3f:d0:0d:de:a9:bc:8c:2f:78:39:b9:ce:c6:c4:0f:ce:86
 
Signature Algorithm: sha256WithRSAEncryption
  
Signature Algorithm: sha256WithRSAEncryption
 
Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
  
Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
 
Validity
  
Validity
−
Not Before: Oct 2 16:16:55 2022 GMT
 +
Not Before: Nov 4 09:26:50 2022 GMT
−
Not After : Sep 27 16:17:25 2042 GMT
 +
Not After : Oct 30 09:27:20 2042 GMT
−
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, postalCode = 61172, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service ETCd
 +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, CN = Intermediate CA for service kubelet CLIENT_AUTH
 
Subject Public Key Info:
  
Subject Public Key Info:
 
Public Key Algorithm: rsaEncryption
  
Public Key Algorithm: rsaEncryption
−
RSA Public-Key: (2048 bit)
 +
Public-Key: (2048 bit)
 
Modulus:
  
Modulus:
  +
...
−
00:c3:e0:4a:5f:01:61:40:a4:0f:37:6a:32:72:71:
  
−
f3:d4:e5:5a:2a:dd:b0:3b:f8:d2:c2:5c:08:80:bf:
  
−
14:aa:1b:32:97:56:95:b0:4c:0e:19:99:78:59:28:
  
−
3e:f0:ee:96:65:88:cc:cc:e9:3c:5e:fe:43:54:db:
  
−
a5:1c:47:9c:d9:16:f3:7c:2c:9e:7a:31:3d:37:91:
  
−
d3:29:be:8b:10:de:52:5f:ff:35:5b:23:3a:61:f8:
  
−
d1:6d:9f:b9:06:7a:8f:74:bf:0c:b7:c6:1b:17:4e:
  
−
15:ce:53:b3:e6:a4:44:74:d3:c8:3e:67:7c:8b:0c:
  
−
c2:0c:43:b4:c0:d2:69:ff:68:37:db:a0:c7:c1:2a:
  
−
9d:0b:41:9f:9a:50:cd:aa:75:13:56:f9:f1:1e:49:
  
−
3e:1a:c9:fb:67:1e:a0:7e:0d:a9:72:9b:bb:86:5a:
  
−
5a:9c:d5:1f:b4:63:4e:b7:f5:00:ea:64:9c:20:63:
  
−
47:d6:69:c6:5f:83:8c:17:21:da:a8:09:63:49:67:
  
−
0f:7e:f7:a9:a1:4a:9e:d1:93:0e:86:4a:44:97:aa:
  
−
08:d0:48:62:80:7c:a3:c2:9c:cc:50:b8:e9:d4:98:
  
−
4f:30:68:93:04:10:53:84:7d:c2:80:24:fb:23:19:
  
−
23:6b:fc:23:41:09:0a:71:6d:b1:81:7b:9e:b9:0d:
  
−
bb:17
  
 
Exponent: 65537 (0x10001)
  
Exponent: 65537 (0x10001)
 
X509v3 extensions:
  
X509v3 extensions:
Строка 296: Строка 754:
 
CA:TRUE
  
CA:TRUE
 
X509v3 Subject Key Identifier:
  
X509v3 Subject Key Identifier:
−
40:7F:6C:D5:D3:43:B3:CF:0F:5C:96:E7:6B:AC:3F:19:4D:8B:49:34
 +
50:35:A5:C5:B4:C6:FC:65:04:08:76:F7:FB:56:D3:76:6D:96:36:2F
 
X509v3 Authority Key Identifier:
  
X509v3 Authority Key Identifier:
−
keyid:02:F8:85:2B:75:F8:E1:1C:69:28:30:32:21:2D:86:71:AF:AB:EC:3C
 +
02:F8:85:2B:75:F8:E1:1C:69:28:30:32:21:2D:86:71:AF:AB:EC:3C
−  
 
Authority Information Access:
  
Authority Information Access:
 
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_root_ca/ca
  
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_root_ca/ca
−  
 
X509v3 CRL Distribution Points:
  
X509v3 CRL Distribution Points:
−  
 
Full Name:
  
Full Name:
 
URI:http://vault.home:8200/v1/k8s_pki_root_ca/crl
  
URI:http://vault.home:8200/v1/k8s_pki_root_ca/crl
  +
...
  +
</PRE>
  +
|-
   
  +
  +
  +
  +
| <code>kubelet</code>
  +
||<code>tlsCertFile</code>, <code>tlsPrivateKeyFile</code>
  +
||<code>kubelet_tls</code>
  +
||Серверный<BR>TLS Web Server<BR>Authentication
  +
|| Используется для <code>HTTP/TLS</CODE> для API <code>kubelet</code> (к которому подключается <code>kube-apiserver</code>, важный параметр - <code>kubelet</code>должен регистрироваться в <code>kube-apiserver</code> с одним из имен разрешенных для использования в сертификате.
  +
||
  +
Обратить внимание что в сертификате прописаны несколько возможных имен
  +
* DNS:kubelet.az1.k8s.cluster.home
  +
* DNS:worker01.az1.k8s.cluster.home - используется как основное, и указано в параметрах <code>kubelet</code>: <code>--hostname-override=${KUBELET_HOSTNAME_OVERRIDE}</code> В примере это '''worker01.az1.k8s.cluster.home'''
  +
* IP Address:10.0.12.1
  +
Сертификат можно просмотреть:
  +
<PRE>
  +
openssl x509 -noout -text -in /etc/k8s/kubelet/certs/tls/kubelet-tls.pem
  +
</PRE>
  +
<PRE>
  +
Certificate:
  +
Data:
  +
Version: 3 (0x2)
  +
Serial Number:
  +
18:6e:c4:32:a9:b7:ba:44:55:0d:52:df:d3:fb:e4:75:f0:29:7b:72
  +
Signature Algorithm: sha256WithRSAEncryption
  +
Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kubelet TLS
  +
Validity
  +
Not Before: Nov 13 16:08:12 2022 GMT
  +
Not After : Nov 12 16:08:41 2027 GMT
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kubelet.az1.k8s.cluster.home
  +
Subject Public Key Info:
  +
Public Key Algorithm: rsaEncryption
  +
Public-Key: (2048 bit)
  +
Modulus:
  +
...
  +
Exponent: 65537 (0x10001)
  +
X509v3 extensions:
  +
X509v3 Key Usage: critical
  +
Digital Signature, Key Encipherment
  +
X509v3 Extended Key Usage:
  +
TLS Web Server Authentication
  +
X509v3 Subject Key Identifier:
  +
42:97:B0:18:FC:0A:03:29:02:92:68:A5:F3:5B:A5:48:23:F1:14:DC
  +
X509v3 Authority Key Identifier:
  +
F1:9C:3B:FB:01:4E:9A:3F:F5:E8:28:CE:99:60:9F:E3:5E:51:DA:C8
  +
Authority Information Access:
  +
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kubelet_tls/ca
  +
X509v3 Subject Alternative Name:
  +
DNS:kubelet.az1.k8s.cluster.home, DNS:worker01.az1.k8s.cluster.home, IP Address:10.0.12.1
  +
X509v3 CRL Distribution Points:
  +
Full Name:
  +
URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kubelet_tls/crl
 
Signature Algorithm: sha256WithRSAEncryption
  
Signature Algorithm: sha256WithRSAEncryption
  +
Signature Value:
−
00:64:66:1a:0c:dd:1c:ce:70:d3:45:e8:b3:4d:c1:7b:48:da:
  
  +
...
−
b7:6e:02:49:0b:24:54:20:07:16:15:7d:74:93:7b:bf:86:15:
  
−
b9:95:06:1d:5b:1b:da:6d:0c:42:6c:39:6f:75:86:a3:62:7d:
  
−
94:da:88:3b:41:13:82:7c:ea:bf:27:be:66:3d:c3:71:eb:58:
  
−
68:76:77:d3:44:69:bf:94:05:a9:03:5d:79:b4:18:3b:c3:0f:
  
−
d3:73:6f:a8:fa:e5:b2:c7:06:9a:35:90:f2:cc:0a:44:a2:01:
  
−
8e:c2:20:56:54:2e:58:c2:bf:df:49:39:41:71:17:f4:dc:ac:
  
−
fe:9d:e0:97:e3:9f:2b:a3:00:9e:12:84:ea:f6:0e:9d:e3:69:
  
−
5d:31:c9:3a:5c:bf:d1:ba:32:35:ff:bf:f8:c9:05:80:57:8b:
  
−
6d:ef:e0:c4:d8:32:26:ef:02:55:87:da:1a:34:38:15:03:6a:
  
−
0e:8c:b7:94:c7:5e:a7:02:ac:b6:63:a8:d3:99:b7:ff:aa:ac:
  
−
ea:31:1f:55:58:d2:7f:dd:21:31:b0:5b:75:e9:73:a5:ed:ff:
  
−
79:cb:58:11:ce:59:a9:17:6a:35:f7:a8:e6:5b:91:31:89:af:
  
−
90:1a:2b:98:c4:32:39:ad:ea:b1:70:8e:8d:cc:b1:41:9e:21:
  
−
bd:72:15:24
  
 
</PRE>
  
</PRE>
  +
|-
   
  +
|}
−
==Валидация с помошью корневого CA==
  
−
* '''k8s_root_certificate.pem''' это файл корневого СА (получен при создании корневого сертификата [[Vault_PKI_Kubernetes_the_hard_way_v2_Root_CA#.D0.9F.D0.BE.D0.B4.D0.B3.D0.BE.D1.82.D0.BE.D0.B2.D0.BA.D0.B0_.D1.84.D0.B0.D0.B9.D0.BB.D0.BE.D0.B2_.D1.81_.D1.81.D0.B5.D1.80.D1.82.D0.B5.D1.84.D0.B8.D0.BA.D0.B0.D1.82.D0.BE.D0.BC_.D0.B8_.D0.BA.D0.BB.D1.8E.D1.87.D0.B5.D0.BC|Корневой CA]])
 
   
  +
=Файлы <code>kubeconfig</code>=
−
* В общем случае этот файл НЕ ЯВЛЯЕТСЯ секретными и всегда должен быть доступен для получения так как именно с ним происходит проверка сертификатов
  
  +
Некоторые сервисы используют <code>kubeconfig</code> для авторизации у <code>kube-apiserver</code>, в том числе плюс-минус такой же конфиг используется для авторизации администратора
  +
<br>
  +
==Описание формата <code>kubeconfig</code>==
  +
Разберем пример файла (для примера взят конфиг от <code>kubelet</code>)
 
<PRE>
  
<PRE>
  +
apiVersion: v1
−
echo "-----BEGIN CERTIFICATE-----" > k8s_root_certificate.pem && curl "http://vault.home:8200/v1/k8s_pki_root_ca/ca" | base64 >> k8s_root_certificate.pem && echo "-----END CERTIFICATE-----" >> k8s_root_certificate.pem
  
  +
clusters:
  +
- cluster:
  +
certificate-authority: "/etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem"
  +
server: https://kube-apiserver.k8s.cluster.home:443
  +
name: kubernetes-the-hardest-way
  +
contexts:
  +
- context:
  +
cluster: kubernetes-the-hardest-way
  +
user: system:node:worker01.az1.k8s.cluster.home
  +
name: default
  +
current-context: default
  +
kind: Config
  +
preferences: {}
  +
users:
  +
- name: system:node:worker01.az1.k8s.cluster.home
  +
user:
  +
client-certificate: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.pem
  +
client-key: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.key
 
</PRE>
  
</PRE>
   
  +
===clusters===
  +
В этой секции описываются кластера, а именно
  +
* имя кластера
  +
<code> name: kubernetes-the-hardest-way</code>
  +
* Адрес по которому доступен <code>kube-apiserver</code>
  +
<code>server: https://kube-apiserver.k8s.cluster.home:443</code>
  +
* CA файл, с помощью которого можно проверить что подключение происходит к правильному кластеру
  +
<code>certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem</code>
  +
  +
Имя кластера можно выбрать произвольно, это имя служит только для связывания различных секций файла в единый контекст
  +
  +
===users===
  +
В этой секции содержится описание пользователя, а именно:
  +
* Имя пользователя
  +
<code>- name: system:node:worker01.az1.k8s.cluster.home</code>
  +
* Способ авторизации и параметры авторизации (в этом случае используются клиентские сертификаты
  +
** <code>client-certificate: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.pem</code>
  +
** <code>client-key: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.key</code>
  +
<BR>
  +
'''Имя пользователя в этой секции - просто идентификатор и никак не участвует в процессе авторизации, а служит только для связывания различных секций файла в единый контекст'''<br>
  +
<BR>
  +
<BR>
  +
<big><big>'''Важно: Фактические имя пользователя и группа описаны в полях <code>CN</code> (имя пользователя) и <code>O</code> (группа) при авторизации с помощью клиентских сертификатов !!!'''</big></big>
  +
<BR>
  +
<br>Имя в сертификате может не совпадать с полем <code>name</code>, иногда они совпадают для удобства конфигурирования но не более того.
  +
  +
===contexts===
  +
Эта секция служит для связывания секций <code>users</code> и <code>clusters</code> и по сути просто сообщает для какого кластера какой пользователь используется.
  +
<br>
  +
Имя контекста <code>name</code> служит для идентификации, так как в одном файле может быть описано множество контекстов (с возможностью переключения между ними)
  +
<BR>
  +
Пример файла следует читать так:<br>
  +
Для контекста с именем <code>default</code> использовать СА и адрес определенные в секции <code>clusters</code> в секции где имя кластера <code>kubernetes-the-hardest-way</code>,<br>
  +
для авторизации использовать данные из секции <code>users</code> где имя <code>name</code> - <code>system:node:worker01.az1.k8s.cluster.home</code>
  +
<br>
  +
При этом слово <code>default</code> в имени контекста не несет какого-то магического смысла - это просто название, на которое можно сослаться, и не более того.
 
<PRE>
  
<PRE>
  +
contexts:
−
openssl \
  
  +
- context:
−
verify \
  
  +
cluster: kubernetes-the-hardest-way
−
-verbose \
  
  +
user: system:node:worker01.az1.k8s.cluster.home
−
-CAfile k8s_root_certificate.pem \
  
  +
name: default
−
k8s_pki_intermediate_ca_for_service_etcd_certificate.pem</PRE>
  
 
</PRE>
  
</PRE>
  +
  +
===current-contex===
  +
Эта секция определяет какой контекст будет использоваться по-умолчанию
  +
<br>
  +
В примере ниже используется по умолчанию контекст с именем <code>default</code>, и здесь слово '''default''' не имеет никакого магического значение - это просто имя контекста определенного в секции <code>contexts</code> и не более того
 
<PRE>
  
<PRE>
  +
current-context: default
−
k8s_pki_intermediate_ca_for_service_etcd_certificate.pem: OK
  
  +
</PRE>
  +
==Общие части для всех kubeconfig==
  +
===clusters===
  +
Так-как это все <code>kubeconfig</code>для одного кластера то у всех их есть общая часть
  +
<PRE>
  +
clusters:
  +
- cluster:
  +
certificate-authority-data: LS0tLS1CRUdJ ... skipped long line ...
  +
server: https://kube-apiserver.k8s.cluster.home:443
  +
name: kubernetes-the-hardest-way
  +
</PRE>
  +
<PRE>
  +
clusters:
  +
- cluster:
  +
certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem
  +
server: https://kube-apiserver.k8s.cluster.home:443
  +
</PRE>
  +
Отличие тут только в том что для админа данные сертификата включены в файл <code>kubeconfig</code> для того что бы его было проще передавать между пользователями
  +
<br>
  +
Для сервисов же указан путь к СА сертификату <code>kube-apiserver</code>
  +
<br>
  +
Назначения этого сертификата - проверка того что подключение идет к тому кластеру к которому ожидается.
  +
===users===
  +
Секция <code>users</code> тоже имеет похожий вид, но тут для каждого сервиса указан свой пользователь и своя группа внутри сертификата (в поле <code>CN</code> указано имя пользователя, в поле <code>O</code> указана группа)<br>
  +
Так-как все файлы очень похожи далее я буду акцентировать внимание на пользователях и группах
  +
<br>
  +
'''Все клиентские сертификаты подписаны одним и тем же СА - <code>kube_apiserver_client_auth</code>''' и процесс <code>kube-apiserver</code> может проверить каждый из них используя СА указанный в параметре <code>--client-ca-file</code> сертификат.
  +
<PRE>
  +
users:
  +
- name: some-name
  +
user:
  +
client-certificate: some-cert.pem
  +
client-key: some-key.key
 
</PRE>
  
</PRE>
   
  +
==Admin==
−
==Валидация ключа==
  
−
Для того что бы проверить подходит ли ключ к сертификату нужно выполнить 2 команды, результат должен совпасть
  
 
<PRE>
  
<PRE>
  +
apiVersion: v1
−
openssl rsa -noout -modulus -in k8s_pki_intermediate_ca_for_service_etcd_certificate.key | openssl md5
  
  +
clusters:
  +
- cluster:
  +
certificate-authority-data: LS0tLS1CRUdJ ... skipped long line ...
  +
server: https://kube-apiserver.k8s.cluster.home:443
  +
name: kubernetes-the-hardest-way
  +
contexts:
  +
- context:
  +
cluster: kubernetes-the-hardest-way
  +
user: admin
  +
name: default
  +
current-context: default
  +
kind: Config
  +
preferences: {}
  +
users:
  +
- name: admin
  +
user:
  +
client-certificate-data: LS0tLS1CRUdJT ... skipped long line ...
  +
client-key-data: LS0tLS1CRUdJTiB ... skipped long line
 
</PRE>
  
</PRE>
  +
Просмотр сертификата
 
<PRE>
  
<PRE>
  +
openssl x509 -noout -text -in admin.pem | grep "Subject:"
−
(stdin)= c026a652ba528c71304454f4088b0669
  
  +
</PRE>
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:masters, OU = system, CN = admin
 
</PRE>
  
</PRE>
  +
* группа <code> O = system:masters</code>
  +
* Пользователь <code>CN = admin</code>
  +
* Права назначаются СlusterRoleBinding на группу:
 
<PRE>
  
<PRE>
  +
kind: Group
−
openssl x509 -noout -modulus -in k8s_pki_intermediate_ca_for_service_etcd_certificate.pem | openssl md5
  
  +
name: system:masters
 
</PRE>
  
</PRE>
  +
'''Имя ClusterRoleBinding получено методом полного перебора что бы понять в каком из них происходит назначение прав на группу <code>system:masters</code>. Для остальных групп - аналогично, хотя часто имя binding совпадает с названием группы. '''
  +
<BR>
  +
Полный вывод:
  +
<PRE>
  +
kubectl get clusterrolebinding cluster-admin -o yaml
  +
</pre>
 
<PRE>
  
<PRE>
  +
apiVersion: rbac.authorization.k8s.io/v1
−
(stdin)= c026a652ba528c71304454f4088b0669
  
  +
kind: ClusterRoleBinding
  +
metadata:
  +
annotations:
  +
rbac.authorization.kubernetes.io/autoupdate: "true"
  +
creationTimestamp: "2022-11-08T09:41:39Z"
  +
labels:
  +
kubernetes.io/bootstrapping: rbac-defaults
  +
name: cluster-admin
  +
resourceVersion: "145"
  +
uid: cea153e2-ead5-4fcc-8810-c615d1204fec
  +
roleRef:
  +
apiGroup: rbac.authorization.k8s.io
  +
kind: ClusterRole
  +
name: cluster-admin
  +
subjects:
  +
- apiGroup: rbac.authorization.k8s.io
  +
kind: Group
  +
name: system:masters
 
</PRE>
  
</PRE>
   
  +
==<code>kube-controller-manager</code>==
−
=Конфигурация Vault для использования промежуточного CA=
  
  +
<PRE>
−
==Загрузка промежуточного сертефиката==
  
  +
apiVersion: v1
−
* '''k8s_pki_intermediate_ca_for_service_etcd_certificate.pem''' - имя файла (сохранен на предыдущем шаге)
  
  +
clusters:
  +
- cluster:
  +
certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem
  +
server: https://kube-apiserver.k8s.cluster.home:443
   
  +
name: kubernetes-the-hardest-way
  +
contexts:
  +
- context:
  +
cluster: kubernetes-the-hardest-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/certs/client_auth/kube-apiserver-client_auth.pem
  +
client-key: /etc/k8s/kube-controller-manager/certs/client_auth/kube-apiserver-client_auth.key
  +
</PRE>
  +
Аналогично админу - можно проверить пользователя, группу и права
 
<PRE>
  
<PRE>
  +
openssl x509 -noout -text -in /etc/k8s/kube-controller-manager/certs/client_auth/kube-apiserver-client_auth.pem | grep "Subject:"
−
vault \
  
  +
</PRE>
−
write \
  
  +
<PRE>
−
k8s_pki_intermediate_ca_for_service_etcd/intermediate/set-signed \
  
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:kube-controller-manager, OU = system, CN = system:kube-controller-manager
−
certificate=@k8s_pki_intermediate_ca_for_service_etcd_certificate.pem</PRE>
  
  +
</PRE>
  +
<PRE>
  +
kubectl get clusterrolebinding system:kube-controller-manager -o yaml
  +
</PRE>
  +
<PRE>
  +
apiVersion: rbac.authorization.k8s.io/v1
  +
kind: ClusterRoleBinding
  +
metadata:
  +
annotations:
  +
rbac.authorization.kubernetes.io/autoupdate: "true"
  +
creationTimestamp: "2022-11-08T09:41:39Z"
  +
labels:
  +
kubernetes.io/bootstrapping: rbac-defaults
  +
name: system:kube-controller-manager
  +
resourceVersion: "151"
  +
uid: 53b7d64d-f3f6-49bc-8954-6c8eea6fb444
  +
roleRef:
  +
apiGroup: rbac.authorization.k8s.io
  +
kind: ClusterRole
  +
name: system:kube-controller-manager
  +
subjects:
  +
- apiGroup: rbac.authorization.k8s.io
  +
kind: User
  +
name: system:kube-controller-manager
  +
</PRE>
   
  +
==<code>kube-proxy</code>==
 
<PRE>
  
<PRE>
  +
apiVersion: v1
−
Success! Data written to: k8s_pki_intermediate_ca_for_service_etcd/intermediate/set-signed
  
  +
clusters:
  +
- cluster:
  +
certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem
  +
server: https://kube-apiserver.k8s.cluster.home:443
  +
name: kubernetes-the-hardest-way
  +
  +
contexts:
  +
- context:
  +
cluster: kubernetes-the-hardest-way
  +
user: system:kube-proxy
  +
name: default
  +
current-context: default
  +
  +
kind: Config
  +
preferences: {}
  +
users:
  +
- name: system:kube-proxy
  +
user:
  +
client-certificate: /etc/k8s/kube-proxy/certs/client_auth/kube-apiserver-client_auth.pem
  +
client-key: /etc/k8s/kube-proxy/certs/client_auth/kube-apiserver-client_auth.key
 
</PRE>
  
</PRE>
   
  +
Аналогично админу - можно проверить пользователя, группу и права
−
Если же использовался экспортируемый сертификат то требуется добавить ключ
  
 
<PRE>
  
<PRE>
  +
openssl x509 -noout -text -in /etc/k8s/kube-proxy/certs/client_auth/kube-apiserver-client_auth.pem | grep "Subject:"
−
vault \
  
  +
</PRE>
−
write \
  
  +
<PRE>
−
k8s_pki_intermediate_ca_for_service_etcd/intermediate/set-signed \
  
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:node-proxier, OU = system, CN = system:kube-proxy
−
certificate=@k8s_pki_intermediate_ca_for_service_etcd_certificate.pem \
  
  +
</PRE>
−
key=@k8s_pki_intermediate_ca_for_service_etcd_certificate.key
  
  +
<PRE>
  +
kubectl get clusterrolebinding system:node-proxier -o yaml
  +
</PRE>
  +
<PRE>
  +
apiVersion: rbac.authorization.k8s.io/v1
  +
kind: ClusterRoleBinding
  +
metadata:
  +
annotations:
  +
rbac.authorization.kubernetes.io/autoupdate: "true"
  +
creationTimestamp: "2022-11-08T09:41:39Z"
  +
labels:
  +
kubernetes.io/bootstrapping: rbac-defaults
  +
name: system:node-proxier
  +
resourceVersion: "150"
  +
uid: 336cfde3-8777-44aa-a70d-e7d1aebd148f
  +
roleRef:
  +
apiGroup: rbac.authorization.k8s.io
  +
kind: ClusterRole
  +
name: system:node-proxier
  +
subjects:
  +
- apiGroup: rbac.authorization.k8s.io
  +
kind: User
  +
name: system:kube-proxy
 
</PRE>
  
</PRE>
   
  +
==<code>kube-scheduler</code>==
−
==Configure URLs==
  
  +
<PRE>
  +
apiVersion: v1
  +
clusters:
  +
- cluster:
  +
certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem
  +
server: https://kube-apiserver.k8s.cluster.home:443
  +
name: kubernetes-the-hardest-way
  +
contexts:
  +
- context:
  +
cluster: kubernetes-the-hardest-way
  +
user: system:kube-scheduler
  +
name: default
  +
current-context: default
  +
kind: Config
  +
preferences: {}
  +
users:
  +
- name: system:kube-scheduler
  +
user:
  +
client-certificate: /etc/k8s/kube-scheduler/certs/client_auth/kube-apiserver-client_auth.pem
  +
client-key: /etc/k8s/kube-scheduler/certs/client_auth/kube-apiserver-client_auth.key
  +
</PRE>
  +
  +
<PRE>
  +
openssl x509 -noout -text -in /etc/k8s/kube-scheduler/certs/client_auth/kube-apiserver-client_auth.pem | grep "Subject:"
  +
</PRE>
  +
<PRE>
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:kube-scheduler, OU = system, CN = system:kube-scheduler
  +
</PRE>
  +
  +
<PRE>
  +
kubectl get clusterrolebinding system:kube-scheduler -o yaml
  +
</PRE>
  +
<PRE>
  +
apiVersion: rbac.authorization.k8s.io/v1
  +
kind: ClusterRoleBinding
  +
metadata:
  +
annotations:
  +
rbac.authorization.kubernetes.io/autoupdate: "true"
  +
creationTimestamp: "2022-11-08T09:41:39Z"
  +
labels:
  +
kubernetes.io/bootstrapping: rbac-defaults
  +
name: system:kube-scheduler
  +
resourceVersion: "153"
  +
uid: 4a50831a-e5f8-4a77-8aef-cea46ac24231
  +
roleRef:
  +
apiGroup: rbac.authorization.k8s.io
  +
kind: ClusterRole
  +
name: system:kube-scheduler
  +
subjects:
  +
- apiGroup: rbac.authorization.k8s.io
  +
kind: User
  +
name: system:kube-scheduler
  +
</PRE>
  +
  +
==<code>kubelet</code>==
  +
<PRE>
  +
apiVersion: v1
  +
clusters:
  +
- cluster:
  +
certificate-authority: "/etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem"
  +
server: https://kube-apiserver.k8s.cluster.home:443
  +
name: kubernetes-the-hardest-way
  +
contexts:
  +
- context:
  +
cluster: kubernetes-the-hardest-way
  +
user: system:node:worker01.az1.k8s.cluster.home
  +
name: default
  +
current-context: default
  +
kind: Config
  +
preferences: {}
  +
users:
  +
- name: system:node:worker01.az1.k8s.cluster.home
  +
user:
  +
client-certificate: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.pem
  +
client-key: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.key
  +
</PRE>
  +
Аналогично админу - можно проверить пользователя, группу и права
  +
<PRE>
  +
openssl x509 -noout -text -in /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.pem | grep "Subject:"
  +
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:nodes, OU = system, CN = system:node:worker01.az1.k8s.cluster.home
  +
</PRE>
  +
Тут есть некоторая тонкость - имя <code>worker01.az1.k8s.cluster.home</code>должно совпадать с хостнеймом или с параметром <code>--hostname-override</code>, и сертификат у <code>kubelet</code>должен позволять использовать это доменное имя (обратить внимание на [[Vault_PKI_Intermediate_CAs_for_ALL_SERVICES_Kubernetes_the_hard_way_v2#kubelet|описание <code>HTTPS/TLS</code> сертификатов <code>kubelet</code>]], описание tlsCertFile, tlsPrivateKeyFile)
  +
<br>
  +
В остальном отличий нет
  +
<PRE>
  +
kubectl get clusterrolebinding system:node -o yaml
  +
</PRE>
 
<PRE>
  
<PRE>
  +
apiVersion: rbac.authorization.k8s.io/v1
−
vault write k8s_pki_intermediate_ca_for_service_etcd/config/urls \
  
  +
kind: ClusterRoleBinding
−
issuing_certificates="http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_etcd/ca" \
  
  +
metadata:
−
crl_distribution_points="http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_etcd/crl"
  
  +
annotations:
  +
rbac.authorization.kubernetes.io/autoupdate: "true"
  +
creationTimestamp: "2022-11-08T09:41:39Z"
  +
labels:
  +
kubernetes.io/bootstrapping: rbac-defaults
  +
name: system:node
  +
resourceVersion: "155"
  +
uid: fec38e51-4833-41af-a46e-fb482e5941b4
  +
roleRef:
  +
apiGroup: rbac.authorization.k8s.io
  +
kind: ClusterRole
  +
name: system:node
 
</PRE>
  
</PRE>

Текущая версия на 20:05, 20 ноября 2022


Эта страница - часть большой статьи про CA используемые в k8s: Vault_PKI_Kubernetes_the_hard_way_v2


Прежде чем начать читать

Эта часть описывает какие именно сертификаты и СА для чего используются разными сервисами - ее можно прочитать перед тем как настаивать Vault для понимания того что и зачем настраивается или после.
Описание настойки Vault для выпуска сертификатов

Некоторые термины и замечания

  • CA: certificate authority или certification authority ( на русском это звучит как Центр Сертефикации)

В контексте документа может иметь несколько возможных значений - как собственно центр выпуска сертификатов, так и сам корневой (или промежуточный сертификат) этого центра. По сути, сертификат СА, который используется для подписания клиентских и серверных сертификатом не только не является секретным, но наоборот должен быть доступен для доступа так как именно он используется для проверки валидности выпущенных сертификатов

В случае с PKI на основе Vault СA доступны для скачивания без авторизации.



Есть 2 типа сертификатов (конечно их больше но в K8s используется 2 типа). Потому в целом (кроме etcd) есть разделение СА в том числе и по типу выпускаемых сертификатов

  • client_auth - этот суффикс у СА используется в значении "сертификаты используются для авторизации" (другими словами - не используются для организации http)
  • tls - этот суффикс у СА используется в значении "сертификаты используются для организации https/TLS"


  • В целом, если не использовать Vault а использовать другой PKI, будь то на основе OpenSSL или чего-то другого ничего принципиально не меняется, и ничего специфичного для PKI Vault в документе нет
  • В этом разделе нет команд по получению сертификатов или настройке PKI, а только описание параметров сервисов, их назначения и свойства сертификатов которые используются.

В целом для лучшего понимания можно держать в голове такую схему 



+-------------+                                     +---------------------------------------------+                                                   +-------------------------------------------------+
| Корневой CA | -------->  им подписан  ------->    |Промежуточный CA для сервиса X и пользования | ------------->     им подписан ---------->        | Конечный сертификат которым пользуется сервис Y |
+-------------+    (процедура подписания          ) +---------------------------------------------+        (процедура подписания скрыта           )   +-------------------------------------------------+
                   (скрыта внутри Vault и         )                                                        (внутри Vault и требует авторизации    )
                   (требует рутовый токен от Vault)                                                        (с логином и паролем, который выдается )
                                                                                                           (тому сервису которому нужен сертификат)

Пример 1

  • Сервису kubelet нужен сертификат для того что бы авторизоваться у kube-apiserver
  • Создается промежуточный CA (внутри Vault) который будет иметь возможность выписывать такие сертификаты, в этом пример это будет СА k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/
  • Сертификат этого промежуточного СА подписывается (или иногда говорят "заверяется", что в контексте SSL синонимы) Корневым СА (на схеме)
    • k8s_pki_intermediate_ca_for_service_ - префикс общий для всех СA которые используются для K8s (в случае Vault используется например для более чем одного кластера, или еще зачем-то)
    • kube_apiserver - имя сервиса, который будет пользоваться сертификатами, в данном контексте "пользоваться" означает то что kube-apiserverбудет проверять эти сертификаты, а не то что они будут непосредственно указаны в его конфигурационных файлах.
    • client_auth - назначение сертификатов которые будут создаваться с помощью этого CA
    • Создаются правила пользования этим СА - какие пользователи и с какими параметрами могут получать сертификаты для авторизации у kube-apiserver, ограничения касаются CN (подробнее об этом - о настройке PKI для Vault, как например настроено получение сертификатов для Etcd
    • Данные для авторизации выдаются сервису, которому нужен сертификат (в примере - kubelet) который используя API Vault может сам выпустить сертификат (с учетом ограничений CN) и при необходимости перевыпустить его.
    • Автоматизация перевыпуска сертификатов - дело будущей настройки сервисов и будет описана в других разделах



Пример 2

  • Сервису kube-apiserver нужно открыть порт и принимать HTTPS/TLS подключения (авторизация после подключения в этом примере пропущена)
  • Для этого требуется серверный сертификат
  • Для выпуска таких сертификатов создается СА k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/, промежуточный сертификат заверяется корневым
  • отличие - в том что он предназначен для HTTPS/TLS и имеет другой суффикс
  • для сервиса kube-apiserver создается пользователь и пароль в Vault (с ограничениями на CN)
  • имея доступ к API Vault, сервис kube-apiserver может выписать себе сертификат с нужным CN (в пределах ограничений) а так же перевыпустить просроченный сертификат



Отличие между примерами в том, что хотя в обоих случаях СА имеют в имени kube-apiserver

  • k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth
  • k8s_pki_intermediate_ca_for_service_kube_apiserver_tls

В первом пример сертификаты выписанные CA с пометкой client_auth используются для того что бы подключиться к kube-apiserver и не фигурируют в его конфигах Во втором же примере сертификаты выписанные СА с пометкой tls используются самим kube-apiserver

Создание СА для работы кластера K8s

Соглашение о путях к файлам

  • Путь к СА: /etc/k8s/shared/certs/CA
  • Все файлы СА (далее по тексту просто СА) можно загрузить из Vault в любой момент, без авторизации. Эти файлы СА (БЕЗ ключа!) не являются секретными, и могут использоваться только для проверки сертификатов (что бы проверить требуется вся цепочка - Корневой CA -- Промежуточный СА -- Сертификат
  • Скрипт загрузки проходится по списку сервисов и загружает с соответствующих endpoints СA в файлы :
  1. kube_apiserver
  2. kube_controller_manager
  3. kube_scheduler
  4. kubelet

в Vault и загружает промежуточные сертификаты в директорию/etc/k8s/shared/certs/CA


K8s использует СА для выписывания сертификатов 2 типов

  • "Обычные" серверные сертификаты (CN = domain)
  • Сертификаты используемые для авторизации - клиентские (CN=username, O=groupname)


Всего в Vault настроены такие СА: 

k8s_pki_intermediate_ca_for_service_etcd/                           pki          pki_13a87e77          PKI Intermediate CA for ETCd service
k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/     pki          pki_622072da          PKI Intermediate CA for K8S: kube-apiserver CLIENT_AUTH
k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/             pki          pki_d8737474          PKI Intermediate CA for K8S: kube-apiserver TLS
k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/    pki          pki_34a63553          PKI Intermediate CA for K8S: kube-controller-manager TLS
k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/             pki          pki_5b5f53f5          PKI Intermediate CA for K8S: kube-scheduler TLS
k8s_pki_intermediate_ca_for_service_kubelet_client_auth/            pki          pki_4f1df8fd          PKI Intermediate CA for K8S: kubelet CLIENT_AUTH
k8s_pki_intermediate_ca_for_service_kubelet_tls/                    pki          pki_47e7182a          PKI Intermediate CA for K8S: kubelet TLS
k8s_pki_root_ca/                                                    pki          pki_8b6cae1e          PKI k8s Root CA

Полный список СА (промежуточных СА!)

  • Всего существует 8 СА которые используются в этой инсталляции (один из них - корневой СА).


Если верить документации, то это не предел - каждый файл с CA в настройках сервисов может содержать
более одного сертификата, другими словами 2 процесса kube-apiserver вполне могут использовать разные CA

В частных случаях можно упростить настройку, и вообще использовать 1 СА
Эта инсталляция подразумевает настойку PKI средней сложности.

k8s_pki_intermediate_ca_for_service_etcd/

k8s_pki_intermediate_ca_for_service_etcd/ - используется для клиентских и серверных сертификатов etcd. Строго говоря, не является частью k8s и настраивается отдельно (Настройка PKI для etcd)

  • для шифрования endpoints
  • для авторизации клиентов

k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/

k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/

  • k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/ - используется для клиентских сертефикатов kube-apiserver, по которым API проверяет права пользователей.
  • k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/ Используется для обеспечения https при подключении к kube-apiserver. При этом происходит двухсторонняя проверка
    • Все клиенты (как сервисы, часть k8s, например kube-controller-manager, kube-scheduler, kubectl так и для администрирования) должны обладать CA (который как и прочие СА не является секретным), для того что бы иметь возможность проверить кластер, другими словами быть уверенным в том что подключаются туда куда ожидают.

Часть kubeconfig отвечающая за этот сертификат: 

clusters:
- cluster:
    certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem
    server: https://kube-apiserver.k8s.cluster.home:443
    • Со своей стороны сервер проверяет как то что сертефикат клиента подписан правильным СА (k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/), так и поля CN O в сертификате, которые используются как имя пользователя и группа. Имена групп выбраны не случайно - для них уже есть (или можно создать свои!) ClusterRoleBindings

k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/

  • k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/ - используется для обеспечения https, серверные сетефикаты для kube-controller-manager (Серверные сертификаты нужны для API)

k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/

  • k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/ - используется для обеспечения https, серверные сетефикаты для kube-scheduler (Серверные сертификаты нужны для API)

k8s_pki_intermediate_ca_for_service_kubelet_client_auth/

 k8s_pki_intermediate_ca_for_service_kubelet_tls/

k8s_pki_intermediate_ca_for_service_kubelet_client_auth/ kubelet в целом устроен аналогично kube-apiserver, и использует 2 СА - один для авторизации клиентов (в случае с kubelet клиентом выступает kube-apiserver), а второй CA используется для обеспечения https

  • У kube-apiserver есть настройка --kubelet-certificate-authority - это файл СА k8s_pki_intermediate_ca_for_service_kubelet_tls/ (другими словами, это тот СА который выписал серверный сертификат для обеспечения HTTPS/TLS API kubelet ( Порт 10250).

Просмотреть содержимое можно например командой 

openssl s_client -connect  127.0.0.1:10250

Используя СА k8s_pki_intermediate_ca_for_service_kubelet_tls kube-apiserver может точно знать что он обращается к нужному kubelet, так как его серверный сертефикат подписан этим СА


  • --kubelet-client-certificate--kubelet-client-key содрежат сертификат, выписанный помощью СА k8s_pki_intermediate_ca_for_service_kubelet_client_auth/ и содержат имя пользователя и группу с которыми kube-apiserver авторизуется у kubelet


Например: O = system:masters, OU = system, CN = kube-apiserver-to-kubelet

При этом по-умолчанию соответствующие ClustetRoleBinding отсутствуют, и перед подключением kubelet их требуется создать дополнительно. (эта часть настройки выполняется при конфигурировании kube-apiserver


  • k8s_pki_intermediate_ca_for_service_kubelet_tls/ - используется для обеспечения https, серверные сетефикаты

k8s_pki_root_ca/

  • k8s_pki_root_ca/ - это корневой СА которым подписаны все промежуточные СА, и его сертификат СА обязательно требуется распространить по всем хостам так как он является полностью доверенным (в пределах этой инсталляции, конечно)

Полный список сертификатов с кратким описанием

Это CA (в VAULT, c именами и описаниями) которые используются для выпуска сертификатов для k8s) 

k8s_pki_intermediate_ca_for_service_etcd/                           pki          pki_13a87e77          PKI Intermediate CA for ETCd service
k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/     pki          pki_622072da          PKI Intermediate CA for K8S: kube-apiserver CLIENT_AUTH
k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/             pki          pki_d8737474          PKI Intermediate CA for K8S: kube-apiserver TLS
k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/    pki          pki_34a63553          PKI Intermediate CA for K8S: kube-controller-manager TLS
k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/             pki          pki_5b5f53f5          PKI Intermediate CA for K8S: kube-scheduler TLS
k8s_pki_intermediate_ca_for_service_kubelet_client_auth/            pki          pki_4f1df8fd          PKI Intermediate CA for K8S: kubelet CLIENT_AUTH
k8s_pki_intermediate_ca_for_service_kubelet_tls/                    pki          pki_47e7182a          PKI Intermediate CA for K8S: kubelet TLS

Note: так как префикс k8s_pki_intermediate_ca_for_service_ в именовании CA общий, то в таблице для удобства форматирования он опущен


kube-apiserver

Сертификаты K8s kube-apiserver
Сервис который использует этот сертификат Параметр сервиса СА выпустивший сертификат Тип сертификата (серверный/клиентский/CA) Назначение Subject и подробности
kube-apiserver --etcd-certfile
--etcd-keyfile 		etcd Клиентский
TLS Web Client
Authentication 		Авторизация в etcd. В зависимости от настроек содержит имя пользователя
если etcd настроен на такой тип авторизации, используется именно такой способ: (etcd: авторизация с использованием сертификатов) 
openssl x509 -noout -text -in /etc/k8s/kube-apiserver/certs/etcd/kube-apiserver.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            56:ce:57:67:7d:9b:54:76:6d:60:51:4a:0c:09:c7:11:ac:f1:95:3b
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, postalCode = 61172, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service ETCd
        Validity
            Not Before: Oct 17 15:23:37 2022 GMT
            Not After : Oct 16 15:24:04 2027 GMT
        Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st 322 app. 311, postalCode = 61172, O = Home Network, OU = IT, CN = kube-apiserver-1
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Subject Key Identifier:
                F8:E5:28:79:2F:4E:99:EA:BE:43:B7:CA:6C:1B:20:65:E6:0B:B3:72
            X509v3 Authority Key Identifier:
                60:41:31:79:58:90:A9:63:62:C2:26:FD:8F:02:B6:07:1A:1D:5C:50
            Authority Information Access:
                CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_etcd/ca
            X509v3 Subject Alternative Name:
                DNS:kube-apiserver-1
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_etcd/crl
kube-apiserver --tls-cert-file
--tls-private-key-file
 kube_apiserver_tls/ Серверный
TLS Web Server
Authentication 		HTTPS для API Можно получить 
netstat -ntpl | grep kube-api 
tcp        0      0 10.0.12.1:6443          0.0.0.0:*               LISTEN      85224/kube-apiserve

Или взять из параметров kube-apiserver
Обратить внимание - в Alt Names прописан как основной домен (kube-apiserver.az1.k8s.cluster.home), так и домен балансера (kube-apiserver.k8s.cluster.home) а так же адреса по которым может быть доступен сервис. Адрес 10.80.0.1 указывается в настройках kube-apiserver

  • DNS:kube-apiserver.az1.k8s.cluster.home
  • DNS:kube-apiserver.k8s.cluster.home
  • DNS:kubernetes
  • DNS:kubernetes.cluster.home
  • IP Address:10.0.12.1
  • IP Address:10.80.0.1
  • IP Address:127.0.0.1
openssl x509 -noout -text -in /etc/k8s/kube-apiserver/certs/tls/kube-apiserver-tls.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            71:a8:93:84:83:df:af:ba:78:df:63:3d:fe:4d:7f:f4:22:26:23:24
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-apiserver TLS
        Validity
            Not Before: Nov 14 08:59:08 2022 GMT
            Not After : Nov 13 08:59:35 2027 GMT
        Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-apiserver.az1.k8s.cluster.home
        Subject Public Key Info:
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Key Identifier:
                E0:69:16:9A:99:A8:E6:95:AB:2B:2D:BC:58:CF:5C:E0:61:BF:10:51
            X509v3 Authority Key Identifier:
                22:7D:70:47:DB:79:ED:91:79:B3:51:0E:23:5F:32:B9:37:01:8D:C1
            Authority Information Access:
                CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/ca
            X509v3 Subject Alternative Name:
                DNS:kube-apiserver.az1.k8s.cluster.home, DNS:kube-apiserver.k8s.cluster.home, DNS:kubernetes, DNS:kubernetes.cluster.home, IP Address:10.0.12.1, IP Address:10.80.0.1, IP Address:127.0.0.1
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/crl
kube-apiserver --client-ca-file CA kube_apiserver_client_auth/ Не серверный
Не клиентский
CA 		Это СА который используется для проверки сертификатов, с которыми клиенты (другие сервисы или пользователи) подключаются к kube-apiserver.

Важно, что ключ от этого сертификата в настройках kube-apiserver не участвует.
Это означает что kube-apiserver может проверять сертификаты клиентов но не может выписывать новые сертификаты, эта часть - за администратором системы.


Именно с пмощью этого СА проверяются сертификаты как пользователей (если пользователи используют сертификаты) так и сервисов kube-controller-manager, kube-proxy, kube-scheduler, kubelet
В случае PKI на основе Vault CA в любой момент можно скачать. 

openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1a:ba:2f:66:84:5f:65:d4:cf:65:e2:d8:86:6a:a5:22:fd:57:8c:2b
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
        Validity
            Not Before: Nov  5 10:21:06 2022 GMT
            Not After : Oct 31 10:21:36 2042 GMT
        Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, CN = Intermediate CA for service kube-apiserver CLIENT_AUTH
        Subject Public Key Info:
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                2F:8E:7A:14:33:0D:E1:66:69:81:85:F5:C5:EC:09:3E:89:E1:B7:DF
            X509v3 Authority Key Identifier:
                02:F8:85:2B:75:F8:E1:1C:69:28:30:32:21:2D:86:71:AF:AB:EC:3C
            Authority Information Access:
                CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_root_ca/ca
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://vault.home:8200/v1/k8s_pki_root_ca/crl
kube-apiserver --kubelet-certificate-authority CA
kubelet_tls 		Не серверный
Не клиентский
CA 		Это CA используется для того, что бы проверить сертификат kubelet, и быть уверенным что подключение к правильному kubelet

Этим же СА подписываются сертификаты kubelet для TLS
(конфигурация kubelet) /etc/k8s/kubelet/kubelet-config.yaml 

tlsCertFile: "/etc/k8s/kubelet/certs/tls/kubelet-tls.pem"
tlsPrivateKeyFile: "/etc/k8s/kubelet/certs/tls/kubelet-tls.key"

openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kubelet_tls.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            33:04:63:a1:86:f2:80:bd:96:5e:10:46:ae:d5:c8:28:89:d0:74:34
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
        Validity
            Not Before: Nov 10 14:11:32 2022 GMT
            Not After : Nov  5 14:12:02 2042 GMT
        Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kubelet TLS
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                F1:9C:3B:FB:01:4E:9A:3F:F5:E8:28:CE:99:60:9F:E3:5E:51:DA:C8
            X509v3 Authority Key Identifier:
                02:F8:85:2B:75:F8:E1:1C:69:28:30:32:21:2D:86:71:AF:AB:EC:3C
            Authority Information Access:
                CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_root_ca/ca
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://vault.home:8200/v1/k8s_pki_root_ca/crl
kube-apiserver --kubelet-client-certificate
--kubelet-client-key 		kubelet_client_auth/ Клиентский
TLS Web Clien
Authentication 		Это сертификат используется kube-apiserver что бы авторизоваться у kubelet
, это нужно что бы kubelet мог быть уверен что к нему пришел доверенный kube-apiserver

Обратить внимание на CN = kube-apiserver-to-kubelet - для этого пользователя потребуется создать отдельный ClusterRoleBinding, по-умолчанию его нет. Естественно, что для своих ролей имена можно использовать любые, kube-apiserver-to-kubelet это текстовый идентификатор, который можно назначить по своему усмотрению, но, одинаковый как в сертификате так и в ClusterRoleBinding 

openssl x509 -noout -text -in /etc/k8s/kube-apiserver/certs/client_auth/kubelet-client_auth.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            28:07:04:c7:ce:4a:6e:29:fc:f7:c9:60:00:57:2a:9c:16:ca:53:8f
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, CN = Intermediate CA for service kubelet CLIENT_AUTH
        Validity
            Not Before: Nov 13 14:43:03 2022 GMT
            Not After : Nov 12 14:43:31 2027 GMT
        Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:masters, OU = system, CN = kube-apiserver-to-kubelet
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Subject Key Identifier:
                22:7C:92:2B:A3:5F:53:0F:B5:7A:F2:84:FA:55:C9:51:DD:33:78:E8
            X509v3 Authority Key Identifier:
                50:35:A5:C5:B4:C6:FC:65:04:08:76:F7:FB:56:D3:76:6D:96:36:2F
            Authority Information Access:
                CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kubelet_client_auth/ca
            X509v3 Subject Alternative Name:
                DNS:kube-apiserver-to-kubelet
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kubelet_client_auth/crl

kube-controller-manager

Сертификаты K8s kube-controller-manager
Сервис который использует этот сертификат Параметр сервиса СА выпустивший сертификат Тип сертификата (серверный/клиентский/CA) Назначение Subject и подробности
kube-controller-manager

--tls-cert-file
--tls-private-key-file

kube_controller_manager_tls/ Серверный
TLS Web Server
Authentication 		kube-controller-manager имеет свой API (по умолчанию - на порту 10257), в котором есть как минимум такие endpoints: /healthz, /readyz, /livez, /metrics.

Этот сертификат служит для организации TLS/HTTPS для этого API

Для разрешения доступа без авторизации служит параметр --authorization-always-allow-paths=/healthz,/readyz,/livez,/metrics, где перечислаются endpoints к которым можно получить доступ.

Получить этот сертификат можно непосредственно подключившись к порту 
openssl s_client -connect  kube-controller-manager.az1.k8s.cluster.home:10257

subject=C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-controller-manager.az1.k8s.cluster.home
issuer=C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-controller-manager TLS

Или в соответствующем файле (путь - в конфиге сервиса) 

openssl x509 -noout -text -in  kube-controller-manager-tls.pem

Certificate: 

   Data:
       Version: 3 (0x2)
       Serial Number:
           68:35:c6:9e:d5:7d:c6:c8:ff:64:03:e7:fd:d8:c0:03:ff:ee:ec:50
       Signature Algorithm: sha256WithRSAEncryption
       Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-controller-manager TLS
       Validity
           Not Before: Nov 10 17:18:43 2022 GMT
           Not After : Nov  9 17:19:11 2027 GMT
       Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-controller-manager.az1.k8s.cluster.home
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
               Public-Key: (2048 bit)
               Modulus:

... 

               Exponent: 65537 (0x10001)
       X509v3 extensions:
           X509v3 Key Usage: critical
               Digital Signature, Key Encipherment
           X509v3 Extended Key Usage:
               TLS Web Server Authentication
           X509v3 Subject Key Identifier:
               7A:16:23:C5:0F:42:C2:D2:F2:FD:4C:2F:98:88:62:4D:C7:C6:E0:2A
           X509v3 Authority Key Identifier:
               3A:B0:CE:B4:3E:05:3F:7C:5F:87:24:BA:89:99:03:C6:9F:4C:2E:B1
           Authority Information Access:
               CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/ca
           X509v3 Subject Alternative Name:
               DNS:kube-controller-manager.az1.k8s.cluster.home, DNS:kube-controller-manager.k8s.cluster.home, IP Address:10.0.12.1
           X509v3 CRL Distribution Points:
               Full Name:
                 URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/crl
   Signature Algorithm: sha256WithRSAEncryption
   Signature Value:

...

kube-controller-manager --root-ca-file Root СА Не Серверный
Не Клиентский
CA 		Этот СА которым подписаны сертификаты для HTTPS/TLS для kube-api-server и он используется для проверки серверных сертификатов. Обладая этим CA можно проверить что подключение происходит к правильному kube-apiserver 
openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0c:8b:42:a7:b4:5a:56:0e:b6:72:d0:40:03:70:5c:19:49:03:43:90
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
        Validity
            Not Before: Nov 10 14:09:38 2022 GMT
            Not After : Nov  5 14:10:08 2042 GMT
        Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-apiserver TLS

kube-proxy

Для kube-proxy за исключением kubeconfig сертификаты не используются

kube-scheduler

Сертификаты K8s kube-scheduler
Сервис который использует этот сертификат Параметр сервиса СА выпустивший сертификат Тип сертификата (серверный/клиентский/CA) Назначение Subject и подробности
kube-scheduler --tls-cert-file
--tls-private-key-file 		kube_scheduler_tls Серверный
TLS Web Server
Authentication

kube-scheduler имеет свой API (по умолчанию - на порту 10259), в котором есть как минимум такие endpoints: /healthz, /readyz, /livez, /metrics. Этот сертификат служит для организации TLS/HTTPS для этого API

Для разрешения доступа без авторизации служит параметр --authorization-always-allow-paths=/healthz,/readyz,/livez,/metrics, где перечислаются endpoints к которым можно получить доступ.

Сертификат можно просмотреть: 

 openssl s_client -connect  kube-scheduler.az1.k8s.cluster.home:10259
subject=C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-scheduler.az1.k8s.cluster.home
issuer=C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-scheduler TLS

Или посмотреть в файле (путь к файлу в параметрах сервиса) 

openssl x509 -noout -text -in  kube-scheduler-tls.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            69:35:40:e1:3d:40:4f:f4:f4:0e:a7:a8:6b:cf:ab:5e:78:fd:76:e4
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-scheduler TLS
        Validity
            Not Before: Nov 10 17:43:55 2022 GMT
            Not After : Nov  9 17:44:24 2027 GMT
        Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-scheduler.az1.k8s.cluster.home
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Key Identifier:
                1E:54:7A:95:6C:DF:B4:99:1E:52:AC:33:42:E4:F0:FC:0C:64:55:A0
            X509v3 Authority Key Identifier:
                89:20:99:22:3A:5F:FB:50:26:01:42:BD:36:B6:F6:F3:B7:E4:51:A9
            Authority Information Access:
                CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/ca
            X509v3 Subject Alternative Name:
                DNS:kube-scheduler.az1.k8s.cluster.home, DNS:kube-scheduler.k8s.cluster.home, IP Address:10.0.12.1
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/crl
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
...

kubelet

Для kubelet сертификаты указываются в файле, определенном в параметре --config=/etc/k8s/kubelet/kubelet-config.yaml 

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: "/etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kubelet_client_auth.pem"
authorization:
  mode: Webhook
clusterDomain: "cluster.home"
clusterDNS:
  - "10.80.0.10"
resolvConf: "/run/systemd/resolve/resolv.conf"
runtimeRequestTimeout: "15m"
tlsCertFile: "/etc/k8s/kubelet/certs/tls/kubelet-tls.pem"
tlsPrivateKeyFile: "/etc/k8s/kubelet/certs/tls/kubelet-tls.key"
authorizationMode: Node,RBAC



Сертификаты K8s kubelet
Сервис который использует этот сертификат Параметр сервиса СА выпустивший сертификат Тип сертификата (серверный/клиентский/CA) Назначение Subject и подробности
kubelet clientCAFile Root CA (другими словами этот СА подписан корневым СА, а сам является промежуточным СА) Не серверный
Не клиентский
СА 		Предназначен для проверки сертификатов с которыми подключаются клиенты (насколько я знаю это только kube-apiserver, в его параметрах это --kubelet-client-certificate и

--kubelet-client-key.

Сертификат можно просмотреть: 

openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kubelet_client_auth.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:c2:5c:3f:d0:0d:de:a9:bc:8c:2f:78:39:b9:ce:c6:c4:0f:ce:86
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
        Validity
            Not Before: Nov  4 09:26:50 2022 GMT
            Not After : Oct 30 09:27:20 2042 GMT
        Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, CN = Intermediate CA for service kubelet CLIENT_AUTH
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                50:35:A5:C5:B4:C6:FC:65:04:08:76:F7:FB:56:D3:76:6D:96:36:2F
            X509v3 Authority Key Identifier:
                02:F8:85:2B:75:F8:E1:1C:69:28:30:32:21:2D:86:71:AF:AB:EC:3C
            Authority Information Access:
                CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_root_ca/ca
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://vault.home:8200/v1/k8s_pki_root_ca/crl
...
kubelet tlsCertFile, tlsPrivateKeyFile kubelet_tls Серверный
TLS Web Server
Authentication 		Используется для HTTP/TLS для API kubelet (к которому подключается kube-apiserver, важный параметр - kubeletдолжен регистрироваться в kube-apiserver с одним из имен разрешенных для использования в сертификате.

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

  • DNS:kubelet.az1.k8s.cluster.home
  • DNS:worker01.az1.k8s.cluster.home - используется как основное, и указано в параметрах kubelet: --hostname-override=${KUBELET_HOSTNAME_OVERRIDE} В примере это worker01.az1.k8s.cluster.home
  • IP Address:10.0.12.1

Сертификат можно просмотреть: 

openssl x509 -noout -text -in /etc/k8s/kubelet/certs/tls/kubelet-tls.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            18:6e:c4:32:a9:b7:ba:44:55:0d:52:df:d3:fb:e4:75:f0:29:7b:72
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kubelet TLS
        Validity
            Not Before: Nov 13 16:08:12 2022 GMT
            Not After : Nov 12 16:08:41 2027 GMT
        Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kubelet.az1.k8s.cluster.home
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Key Identifier:
                42:97:B0:18:FC:0A:03:29:02:92:68:A5:F3:5B:A5:48:23:F1:14:DC
            X509v3 Authority Key Identifier:
                F1:9C:3B:FB:01:4E:9A:3F:F5:E8:28:CE:99:60:9F:E3:5E:51:DA:C8
            Authority Information Access:
                CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kubelet_tls/ca
            X509v3 Subject Alternative Name:
                DNS:kubelet.az1.k8s.cluster.home, DNS:worker01.az1.k8s.cluster.home, IP Address:10.0.12.1
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kubelet_tls/crl
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
...

Файлы kubeconfig

Некоторые сервисы используют kubeconfig для авторизации у kube-apiserver, в том числе плюс-минус такой же конфиг используется для авторизации администратора

Описание формата kubeconfig

Разберем пример файла (для примера взят конфиг от kubelet) 

apiVersion: v1
clusters:
- cluster:
    certificate-authority: "/etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem"
    server: https://kube-apiserver.k8s.cluster.home:443
  name: kubernetes-the-hardest-way
contexts:
- context:
    cluster: kubernetes-the-hardest-way
    user: system:node:worker01.az1.k8s.cluster.home
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: system:node:worker01.az1.k8s.cluster.home
  user:
    client-certificate: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.pem
    client-key: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.key

clusters

В этой секции описываются кластера, а именно

  • имя кластера

name: kubernetes-the-hardest-way

  • Адрес по которому доступен kube-apiserver

server: https://kube-apiserver.k8s.cluster.home:443

  • CA файл, с помощью которого можно проверить что подключение происходит к правильному кластеру

certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem

Имя кластера можно выбрать произвольно, это имя служит только для связывания различных секций файла в единый контекст

users

В этой секции содержится описание пользователя, а именно:

  • Имя пользователя

- name: system:node:worker01.az1.k8s.cluster.home

  • Способ авторизации и параметры авторизации (в этом случае используются клиентские сертификаты
    • client-certificate: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.pem
    • client-key: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.key


Имя пользователя в этой секции - просто идентификатор и никак не участвует в процессе авторизации, а служит только для связывания различных секций файла в единый контекст


Важно: Фактические имя пользователя и группа описаны в полях CN (имя пользователя) и O (группа) при авторизации с помощью клиентских сертификатов !!!

Имя в сертификате может не совпадать с полем name, иногда они совпадают для удобства конфигурирования но не более того.

contexts

Эта секция служит для связывания секций users и clusters и по сути просто сообщает для какого кластера какой пользователь используется.
Имя контекста name служит для идентификации, так как в одном файле может быть описано множество контекстов (с возможностью переключения между ними)
Пример файла следует читать так:
Для контекста с именем default использовать СА и адрес определенные в секции clusters в секции где имя кластера kubernetes-the-hardest-way,
для авторизации использовать данные из секции users где имя name - system:node:worker01.az1.k8s.cluster.home
При этом слово default в имени контекста не несет какого-то магического смысла - это просто название, на которое можно сослаться, и не более того. 

contexts:
- context:
    cluster: kubernetes-the-hardest-way
    user: system:node:worker01.az1.k8s.cluster.home
  name: default

current-contex

Эта секция определяет какой контекст будет использоваться по-умолчанию
В примере ниже используется по умолчанию контекст с именем default, и здесь слово default не имеет никакого магического значение - это просто имя контекста определенного в секции contexts и не более того 

current-context: default

Общие части для всех kubeconfig

clusters

Так-как это все kubeconfigдля одного кластера то у всех их есть общая часть 

clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJ ... skipped long line ...
    server: https://kube-apiserver.k8s.cluster.home:443
  name: kubernetes-the-hardest-way

clusters:
- cluster:
    certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem
    server: https://kube-apiserver.k8s.cluster.home:443

Отличие тут только в том что для админа данные сертификата включены в файл kubeconfig для того что бы его было проще передавать между пользователями
Для сервисов же указан путь к СА сертификату kube-apiserver
Назначения этого сертификата - проверка того что подключение идет к тому кластеру к которому ожидается.

users

Секция users тоже имеет похожий вид, но тут для каждого сервиса указан свой пользователь и своя группа внутри сертификата (в поле CN указано имя пользователя, в поле O указана группа)
Так-как все файлы очень похожи далее я буду акцентировать внимание на пользователях и группах
Все клиентские сертификаты подписаны одним и тем же СА - kube_apiserver_client_auth и процесс kube-apiserver может проверить каждый из них используя СА указанный в параметре --client-ca-file сертификат. 

users:
- name: some-name
  user:
    client-certificate: some-cert.pem
    client-key: some-key.key

Admin

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJ ... skipped long line ...
    server: https://kube-apiserver.k8s.cluster.home:443
  name: kubernetes-the-hardest-way
contexts:
- context:
    cluster: kubernetes-the-hardest-way
    user: admin
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: admin
  user:
    client-certificate-data: LS0tLS1CRUdJT ... skipped long line ...
    client-key-data: LS0tLS1CRUdJTiB ... skipped long line

Просмотр сертификата 

openssl x509 -noout -text -in admin.pem | grep "Subject:"

Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:masters, OU = system, CN = admin

  • группа O = system:masters
  • Пользователь CN = admin
  • Права назначаются СlusterRoleBinding на группу:
  kind: Group
  name: system:masters

Имя ClusterRoleBinding получено методом полного перебора что бы понять в каком из них происходит назначение прав на группу system:masters. Для остальных групп - аналогично, хотя часто имя binding совпадает с названием группы.
Полный вывод: 

kubectl get clusterrolebinding cluster-admin -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2022-11-08T09:41:39Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "145"
  uid: cea153e2-ead5-4fcc-8810-c615d1204fec
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

kube-controller-manager

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem
    server: https://kube-apiserver.k8s.cluster.home:443

  name: kubernetes-the-hardest-way
contexts:
- context:
    cluster: kubernetes-the-hardest-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/certs/client_auth/kube-apiserver-client_auth.pem
    client-key: /etc/k8s/kube-controller-manager/certs/client_auth/kube-apiserver-client_auth.key

Аналогично админу - можно проверить пользователя, группу и права 

openssl x509 -noout -text -in  /etc/k8s/kube-controller-manager/certs/client_auth/kube-apiserver-client_auth.pem  | grep "Subject:"

Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:kube-controller-manager, OU = system, CN = system:kube-controller-manager

kubectl get clusterrolebinding system:kube-controller-manager -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2022-11-08T09:41:39Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-controller-manager
  resourceVersion: "151"
  uid: 53b7d64d-f3f6-49bc-8954-6c8eea6fb444
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kube-controller-manager
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: system:kube-controller-manager

kube-proxy

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem
    server: https://kube-apiserver.k8s.cluster.home:443
  name: kubernetes-the-hardest-way

contexts:
- context:
    cluster: kubernetes-the-hardest-way
    user: system:kube-proxy
  name: default
current-context: default

kind: Config
preferences: {}
users:
- name: system:kube-proxy
  user:
    client-certificate: /etc/k8s/kube-proxy/certs/client_auth/kube-apiserver-client_auth.pem
    client-key: /etc/k8s/kube-proxy/certs/client_auth/kube-apiserver-client_auth.key

Аналогично админу - можно проверить пользователя, группу и права 

openssl x509 -noout -text -in /etc/k8s/kube-proxy/certs/client_auth/kube-apiserver-client_auth.pem  | grep "Subject:"

Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:node-proxier, OU = system, CN = system:kube-proxy

kubectl get clusterrolebinding system:node-proxier  -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2022-11-08T09:41:39Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:node-proxier
  resourceVersion: "150"
  uid: 336cfde3-8777-44aa-a70d-e7d1aebd148f
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:node-proxier
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: system:kube-proxy

kube-scheduler

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem
    server: https://kube-apiserver.k8s.cluster.home:443
  name: kubernetes-the-hardest-way
contexts:
- context:
    cluster: kubernetes-the-hardest-way
    user: system:kube-scheduler
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: system:kube-scheduler
  user:
    client-certificate: /etc/k8s/kube-scheduler/certs/client_auth/kube-apiserver-client_auth.pem
    client-key: /etc/k8s/kube-scheduler/certs/client_auth/kube-apiserver-client_auth.key

openssl x509 -noout -text -in  /etc/k8s/kube-scheduler/certs/client_auth/kube-apiserver-client_auth.pem  | grep "Subject:"

Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:kube-scheduler, OU = system, CN = system:kube-scheduler

kubectl get clusterrolebinding system:kube-scheduler -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2022-11-08T09:41:39Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-scheduler
  resourceVersion: "153"
  uid: 4a50831a-e5f8-4a77-8aef-cea46ac24231
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kube-scheduler
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: system:kube-scheduler

kubelet

apiVersion: v1
clusters:
- cluster:
    certificate-authority: "/etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem"
    server: https://kube-apiserver.k8s.cluster.home:443
  name: kubernetes-the-hardest-way
contexts:
- context:
    cluster: kubernetes-the-hardest-way
    user: system:node:worker01.az1.k8s.cluster.home
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: system:node:worker01.az1.k8s.cluster.home
  user:
    client-certificate: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.pem
    client-key: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.key

Аналогично админу - можно проверить пользователя, группу и права 

openssl x509 -noout -text -in  /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.pem   | grep "Subject:"
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:nodes, OU = system, CN = system:node:worker01.az1.k8s.cluster.home

Тут есть некоторая тонкость - имя worker01.az1.k8s.cluster.homeдолжно совпадать с хостнеймом или с параметром --hostname-override, и сертификат у kubeletдолжен позволять использовать это доменное имя (обратить внимание на описание HTTPS/TLS сертификатов kubelet, описание tlsCertFile, tlsPrivateKeyFile)
В остальном отличий нет 

kubectl get clusterrolebinding system:node  -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2022-11-08T09:41:39Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:node
  resourceVersion: "155"
  uid: fec38e51-4833-41af-a46e-fb482e5941b4
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:node
Источник — https://noname.com.ua/mediawiki/index.php?title=Vault_PKI_Intermediate_CAs_for_ALL_SERVICES_Kubernetes_the_hard_way_v2&oldid=10652