Vault PKI Intermediate CAs for ALL SERVICES Kubernetes the hard way v2: различия между версиями
Sirmax (обсуждение | вклад) (→Admin) |
Sirmax (обсуждение | вклад) |
||
(не показано 56 промежуточных версий этого же участника) | |||
Строка 14: | Строка 14: | ||
[[Vault_PKI_Intermediate_SETUP_CAs_for_ALL_SERVICES_Kubernetes_the_hard_way_v2|Описание настойки <code>Vault</code> для выпуска сертификатов]] |
[[Vault_PKI_Intermediate_SETUP_CAs_for_ALL_SERVICES_Kubernetes_the_hard_way_v2|Описание настойки <code>Vault</code> для выпуска сертификатов]] |
||
− | =Некоторые термины= |
+ | =Некоторые термины и замечания= |
* <code>CA</code>: '''certificate authority''' или '''certification authority''' ( на русском это звучит как Центр Сертефикации) |
* <code>CA</code>: '''certificate authority''' или '''certification authority''' ( на русском это звучит как Центр Сертефикации) |
||
В контексте документа может иметь несколько возможных значений - как собственно центр выпуска сертификатов, так и сам корневой (или промежуточный сертификат) этого центра. По сути, сертификат СА, который используется для подписания клиентских и серверных сертификатом не только не является секретным, но наоборот должен быть доступен для доступа так как именно он используется для проверки валидности выпущенных сертификатов |
В контексте документа может иметь несколько возможных значений - как собственно центр выпуска сертификатов, так и сам корневой (или промежуточный сертификат) этого центра. По сути, сертификат СА, который используется для подписания клиентских и серверных сертификатом не только не является секретным, но наоборот должен быть доступен для доступа так как именно он используется для проверки валидности выпущенных сертификатов |
||
Строка 26: | Строка 26: | ||
* <code>client_auth</code> - этот суффикс у СА используется в значении "сертификаты используются для авторизации" (другими словами - не используются для организации <code>http</code>) |
* <code>client_auth</code> - этот суффикс у СА используется в значении "сертификаты используются для авторизации" (другими словами - не используются для организации <code>http</code>) |
||
* <code>tls</code> - этот суффикс у СА используется в значении "сертификаты используются для организации <code>https/TLS</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> |
||
+ | * Сервису <code>kubelet </code> нужен сертификат для того что бы авторизоваться у <code>kube-apiserver</code> |
||
+ | * Создается промежуточный 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= |
=Создание СА для работы кластера 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> |
||
+ | }} |
||
Строка 50: | Строка 140: | ||
=Полный список <code>СА</code> (промежуточных СА!)= |
=Полный список <code>СА</code> (промежуточных СА!)= |
||
− | Всего существует 8 СА которые используются в этой инсталляции (один из них - корневой СА). <br> |
+ | * Всего существует 8 СА которые используются в этой инсталляции (один из них - корневой СА). <br> |
+ | <br> |
||
Если верить документации, то это не предел - каждый файл с CA в настройках сервисов может содержать <br> |
Если верить документации, то это не предел - каждый файл с CA в настройках сервисов может содержать <br> |
||
более одного сертификата, другими словами 2 процесса <code>kube-apiserver</code> вполне могут использовать разные CA<br> |
более одного сертификата, другими словами 2 процесса <code>kube-apiserver</code> вполне могут использовать разные CA<br> |
||
Строка 68: | Строка 159: | ||
* <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_client_auth/</code> - используется для клиентских сертефикатов <code>kube-apiserver</code>, по которым API проверяет права пользователей. |
||
* <code>k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/</code> Используется для обеспечения https при подключении к <code>kube-apiserver</code>. При этом происходит двухсторонняя проверка |
* <code>k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/</code> Используется для обеспечения https при подключении к <code>kube-apiserver</code>. При этом происходит двухсторонняя проверка |
||
− | ** Все клиенты (как сервисы, часть k8s, например kube-controller-manager, kube-scheduler так и |
+ | ** Все клиенты (как сервисы, часть k8s, например <code>kube-controller-manager</code>, <code>kube-scheduler</code>, <code>kubectl</code> так и для администрирования) должны обладать CA (который как и прочие СА не является секретным), для того что бы иметь возможность проверить кластер, другими словами быть уверенным в том что подключаются туда куда ожидают. <br> |
Часть <code>kubeconfig</code> отвечающая за этот сертификат: |
Часть <code>kubeconfig</code> отвечающая за этот сертификат: |
||
<PRE> |
<PRE> |
||
Строка 79: | Строка 170: | ||
=<code>k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/</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>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>= |
||
− | * <code>k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/</code> - используется для обеспечения https, серверные сетефикаты |
+ | * <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> |
||
+ | openssl s_client -connect 127.0.0.1:10250 |
||
+ | </PRE> |
||
+ | Используя СА <code>k8s_pki_intermediate_ca_for_service_kubelet_tls</code> <code>kube-apiserver</code> может |
||
+ | точно знать что он обращается к нужному <code>kubelet</code>, так как его серверный сертефикат подписан этим СА |
||
+ | |||
− | + | * <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> |
|
− | * <code>k8s_pki_intermediate_ca_for_service_kubelet_client_auth/</code> kubelet в целом устроен аналогично kube-api серверу, и использует 2 СА - один для авторизации клиентов (в случае с kubelet клиентом выступает kube-apiserver), а второй используется для обеспечения https |
||
− | ** У <code>kube-apiserver</code> есть настройка <code>--kubelet-certificate-authority</code> - это файлс СА для <code>k8s_pki_intermediate_ca_for_service_kubelet_tls/</code>, таким образом <code>kube-apiserver</code> может точно знать что он обращается к нужному <code>kubelet</code>, так как его серверный сертефикат подписан этим СА |
||
− | ** <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> |
||
<br> |
<br> |
||
Например: <code>O = system:masters</code>, <code>OU = system</code>, <code>CN = kube-apiserver-to-kubelet</code> |
Например: <code>O = system:masters</code>, <code>OU = system</code>, <code>CN = kube-apiserver-to-kubelet</code> |
||
Строка 100: | Строка 202: | ||
=Полный список сертификатов с кратким описанием= |
=Полный список сертификатов с кратким описанием= |
||
− | Это CA (в VAULT, c именами и описаниями) которые используются для выпуска сертификатов для k8s |
+ | Это CA (в <code>VAULT</code>, c именами и описаниями) которые используются для выпуска сертификатов для k8s) |
<PRE> |
<PRE> |
||
k8s_pki_intermediate_ca_for_service_etcd/ pki pki_13a87e77 PKI Intermediate CA for ETCd service |
k8s_pki_intermediate_ca_for_service_etcd/ pki pki_13a87e77 PKI Intermediate CA for ETCd service |
||
Строка 118: | Строка 220: | ||
|+ Сертификаты K8s <code> kube-apiserver</code> |
|+ Сертификаты K8s <code> kube-apiserver</code> |
||
|- |
|- |
||
− | ! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Назначение !! Subject и подробности |
+ | ! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Тип сертификата (серверный/клиентский/CA) !! Назначение !! Subject и подробности |
|- |
|- |
||
| <code>kube-apiserver</code> |
| <code>kube-apiserver</code> |
||
|| <code>--etcd-certfile</code><br><code>--etcd-keyfile</code> |
|| <code>--etcd-certfile</code><br><code>--etcd-keyfile</code> |
||
|| <code>etcd</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>: авторизация с использованием сертификатов]]) |
|| Авторизация в <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> |
||<PRE> |
||
Строка 173: | Строка 276: | ||
| <code>kube-apiserver</code> |
| <code>kube-apiserver</code> |
||
|| <code>--tls-cert-file</code><br> <code>--tls-private-key-file</code><br> |
|| <code>--tls-cert-file</code><br> <code>--tls-private-key-file</code><br> |
||
− | || <code>kube_apiserver_tls/</code> |
+ | || <code>kube_apiserver_tls/</code> |
+ | || Серверный<br>TLS Web Server<br>Authentication |
||
|| <code>HTTPS</code> для API |
|| <code>HTTPS</code> для API |
||
|| Можно получить <PRE>netstat -ntpl | grep kube-api </PRE> |
|| Можно получить <PRE>netstat -ntpl | grep kube-api </PRE> |
||
Строка 242: | Строка 346: | ||
| <code>kube-apiserver</code> |
| <code>kube-apiserver</code> |
||
|| <code>--client-ca-file</code> |
|| <code>--client-ca-file</code> |
||
− | || <code>CA</code> <code>kube_apiserver_client_auth/</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-apiserver</code> может проверять сертификаты клиентов но не может выписывать новые сертификаты, эта часть - за администратором системы. |
Важно, что ключ от этого сертификата в настройках <code>kube-apiserver</code> не участвует. <BR>Это означает что <code>kube-apiserver</code> может проверять сертификаты клиентов но не может выписывать новые сертификаты, эта часть - за администратором системы. |
||
Строка 302: | Строка 407: | ||
| <code>kube-apiserver</code> |
| <code>kube-apiserver</code> |
||
|| <code>--kubelet-certificate-authority</code> |
|| <code>--kubelet-certificate-authority</code> |
||
− | || <code>CA</code><BR><code>kubelet_tls</code> |
+ | || <code>CA</code><BR><code>kubelet_tls</code> |
+ | || Не серверный<BR>Не клиентский<BR>'''CA''' |
||
|| Это <code>CA</code> используется для того, что бы проверить сертификат <code>kubelet</code>, и быть уверенным что подключение к правильному <code>kubelet</code><br> |
|| Это <code>CA</code> используется для того, что бы проверить сертификат <code>kubelet</code>, и быть уверенным что подключение к правильному <code>kubelet</code><br> |
||
Этим же СА подписываются сертификаты <code>kubelet</code> для TLS <BR> (конфигурация <code>kubelet</code>) |
Этим же СА подписываются сертификаты <code>kubelet</code> для TLS <BR> (конфигурация <code>kubelet</code>) |
||
Строка 354: | Строка 460: | ||
| <code>kube-apiserver</code> |
| <code>kube-apiserver</code> |
||
|| <code>--kubelet-client-certificate</code> <br> <code>--kubelet-client-key</code> |
|| <code>--kubelet-client-certificate</code> <br> <code>--kubelet-client-key</code> |
||
− | || <code>kubelet_client_auth/</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>kube-apiserver</code> что бы авторизоваться у <code>kubelet</code><br>, это нужно что бы <code>kubelet</code> мог быть уверен что к нему пришел доверенный <code>kube-apiserver</code> |
||
|| |
|| |
||
Строка 403: | Строка 510: | ||
|+ Сертификаты K8s <code>kube-controller-manager</code> |
|+ Сертификаты K8s <code>kube-controller-manager</code> |
||
|- |
|- |
||
− | ! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Назначение !! Subject и подробности |
+ | ! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Тип сертификата (серверный/клиентский/CA) !! Назначение !! Subject и подробности |
|- |
|- |
||
Строка 411: | Строка 518: | ||
<code>--tls-private-key-file</code> |
<code>--tls-private-key-file</code> |
||
||<code>kube_controller_manager_tls/</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>kube-controller-manager</code> имеет свой API (по умолчанию - на порту 10257), в котором есть как минимум такие endpoints: /healthz, /readyz, /livez, /metrics.<BR> |
||
Этот сертификат служит для организации <code>TLS/HTTPS</code> для этого API |
Этот сертификат служит для организации <code>TLS/HTTPS</code> для этого API |
||
Строка 423: | Строка 531: | ||
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=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 |
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> |
</PRE> |
||
|- |
|- |
||
Строка 440: | Строка 589: | ||
|| --root-ca-file |
|| --root-ca-file |
||
||Root СА |
||Root СА |
||
+ | ||Не Серверный<BR>Не Клиентский<BR>'''CA''' |
||
||Этот СА которым подписаны сертификаты для <code>HTTPS/TLS</code> для <code>kube-api-server</code> и он используется для проверки серверных сертификатов. Обладая этим CA можно проверить что подключение происходит к правильному <code>kube-apiserver</code> |
||Этот СА которым подписаны сертификаты для <code>HTTPS/TLS</code> для <code>kube-api-server</code> и он используется для проверки серверных сертификатов. Обладая этим CA можно проверить что подключение происходит к правильному <code>kube-apiserver</code> |
||
|| |
|| |
||
Строка 472: | Строка 622: | ||
|+ Сертификаты K8s <code>kube-scheduler</code> |
|+ Сертификаты K8s <code>kube-scheduler</code> |
||
|- |
|- |
||
− | ! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Назначение !! Subject и подробности |
+ | ! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Тип сертификата (серверный/клиентский/CA) !! Назначение !! Subject и подробности |
|- |
|- |
||
Строка 478: | Строка 628: | ||
||<code>--tls-cert-file</code> <br> <code>--tls-private-key-file</code> |
||<code>--tls-cert-file</code> <br> <code>--tls-private-key-file</code> |
||
||<code>kube_scheduler_tls</code> |
||<code>kube_scheduler_tls</code> |
||
+ | ||Серверный<BR>TLS Web Server<BR>Authentication |
||
|| |
|| |
||
<code>kube-scheduler</code> имеет свой API (по умолчанию - на порту 10259), в котором есть как минимум такие endpoints: /healthz, /readyz, /livez, /metrics. |
<code>kube-scheduler</code> имеет свой API (по умолчанию - на порту 10259), в котором есть как минимум такие endpoints: /healthz, /readyz, /livez, /metrics. |
||
Строка 489: | Строка 640: | ||
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=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 |
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> |
||
+ | 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: |
||
+ | ... |
||
</PRE> |
</PRE> |
||
|- |
|- |
||
Строка 523: | Строка 715: | ||
|+ Сертификаты K8s <code>kubelet</code> |
|+ Сертификаты K8s <code>kubelet</code> |
||
|- |
|- |
||
− | ! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Назначение !! Subject и подробности |
+ | ! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Тип сертификата (серверный/клиентский/CA) !! Назначение !! Subject и подробности |
|- |
|- |
||
| <code>kubelet</code> |
| <code>kubelet</code> |
||
||<code>clientCAFile</code> |
||<code>clientCAFile</code> |
||
− | ||Root CA ( |
+ | ||Root CA (другими словами этот СА подписан корневым СА, а сам является промежуточным СА) |
+ | || Не серверный<BR>Не клиентский<BR>'''СА''' |
||
|| Предназначен для проверки сертификатов с которыми подключаются клиенты (насколько я знаю это только <code>kube-apiserver</code>, в его параметрах это <code>--kubelet-client-certificate</code> и |
|| Предназначен для проверки сертификатов с которыми подключаются клиенты (насколько я знаю это только <code>kube-apiserver</code>, в его параметрах это <code>--kubelet-client-certificate</code> и |
||
<code>--kubelet-client-key</code>. |
<code>--kubelet-client-key</code>. |
||
Строка 579: | Строка 772: | ||
||<code>tlsCertFile</code>, <code>tlsPrivateKeyFile</code> |
||<code>tlsCertFile</code>, <code>tlsPrivateKeyFile</code> |
||
||<code>kubelet_tls</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:kubelet.az1.k8s.cluster.home |
||
− | * DNS:worker01.az1.k8s.cluster.home - используется как основное, и указано в параметрах <code>kubelet</code>: <code>--hostname-override=${KUBELET_HOSTNAME_OVERRIDE}</code> |
+ | * 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 |
* IP Address:10.0.12.1 |
||
Сертификат можно просмотреть: |
Сертификат можно просмотреть: |
||
Строка 778: | Строка 972: | ||
name: system:masters |
name: system:masters |
||
</PRE> |
</PRE> |
||
− | '''Имя ClusterRoleBinding |
+ | '''Имя ClusterRoleBinding получено методом полного перебора что бы понять в каком из них происходит назначение прав на группу <code>system:masters</code>. Для остальных групп - аналогично, хотя часто имя binding совпадает с названием группы. ''' |
+ | <BR> |
||
Полный вывод: |
Полный вывод: |
||
<PRE> |
<PRE> |
||
Строка 803: | Строка 998: | ||
kind: Group |
kind: Group |
||
name: system:masters |
name: system:masters |
||
− | </ |
+ | </PRE> |
==<code>kube-controller-manager</code>== |
==<code>kube-controller-manager</code>== |
||
Строка 827: | Строка 1022: | ||
client-certificate: /etc/k8s/kube-controller-manager/certs/client_auth/kube-apiserver-client_auth.pem |
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 |
client-key: /etc/k8s/kube-controller-manager/certs/client_auth/kube-apiserver-client_auth.key |
||
+ | </PRE> |
||
+ | Аналогично админу - можно проверить пользователя, группу и права |
||
+ | <PRE> |
||
+ | openssl x509 -noout -text -in /etc/k8s/kube-controller-manager/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-controller-manager, OU = system, CN = system:kube-controller-manager |
||
+ | </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> |
</PRE> |
||
Строка 907: | Строка 1133: | ||
client-certificate: /etc/k8s/kube-scheduler/certs/client_auth/kube-apiserver-client_auth.pem |
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 |
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> |
</PRE> |
||
Строка 930: | Строка 1188: | ||
client-certificate: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.pem |
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 |
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> |
||
+ | 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 |
||
</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
или чего-то другого ничего принципиально не меняется, и ничего специфичного для PKIVault
в документе нет
- В этом разделе нет команд по получению сертификатов или настройке 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
) который используя APIVault
может сам выпустить сертификат (с учетом ограничений 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 в файлы :
- kube_apiserver
- kube_controller_manager
- kube_scheduler
- 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 (который как и прочие СА не является секретным), для того что бы иметь возможность проверить кластер, другими словами быть уверенным в том что подключаются туда куда ожидают.
- Все клиенты (как сервисы, часть k8s, например
Часть 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
APIkubelet
( Порт 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
Сервис который использует этот сертификат | Параметр сервиса | СА выпустивший сертификат | Тип сертификата (серверный/клиентский/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 Или взять из параметров
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 . Важно, что ключ от этого сертификата в настройках
|
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 Этим же СА подписываются сертификаты 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
|
Обратить внимание на 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
Сервис который использует этот сертификат | Параметр сервиса | СА выпустивший сертификат | Тип сертификата (серверный/клиентский/CA) | Назначение | Subject и подробности |
---|---|---|---|---|---|
kube-controller-manager
|
|
kube_controller_manager_tls/
|
Серверный TLS Web Server Authentication |
kube-controller-manager имеет свой API (по умолчанию - на порту 10257), в котором есть как минимум такие endpoints: /healthz, /readyz, /livez, /metrics.Этот сертификат служит для организации
|
Получить этот сертификат можно непосредственно подключившись к порту
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
Сервис который использует этот сертификат | Параметр сервиса | СА выпустивший сертификат | Тип сертификата (серверный/клиентский/CA) | Назначение | Subject и подробности |
---|---|---|---|---|---|
kube-scheduler
|
--tls-cert-file --tls-private-key-file
|
kube_scheduler_tls
|
Серверный TLS Web Server Authentication |
|
Сертификат можно просмотреть: 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
Сервис который использует этот сертификат | Параметр сервиса | СА выпустивший сертификат | Тип сертификата (серверный/клиентский/CA) | Назначение | Subject и подробности |
---|---|---|---|---|---|
kubelet
|
clientCAFile
|
Root CA (другими словами этот СА подписан корневым СА, а сам является промежуточным СА) | Не серверный Не клиентский СА |
Предназначен для проверки сертификатов с которыми подключаются клиенты (насколько я знаю это только kube-apiserver , в его параметрах это --kubelet-client-certificate и
|
Сертификат можно просмотреть: 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 с одним из имен разрешенных для использования в сертификате.
|
Обратить внимание что в сертификате прописаны несколько возможных имен
Сертификат можно просмотреть: 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