Vault PKI Intermediate CAs for ALL SERVICES Kubernetes the hard way v2: различия между версиями
Sirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) |
||
(не показано 136 промежуточных версий этого же участника) | |||
Строка 9: | Строка 9: | ||
+ | =Прежде чем начать читать= |
||
− | =Некоторые термины= |
||
+ | Эта часть описывает какие именно сертификаты и СА для чего используются разными сервисами - ее можно прочитать перед тем как настаивать <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''' ( на русском это звучит как Центр Сертефикации) |
* <code>CA</code>: '''certificate authority''' или '''certification authority''' ( на русском это звучит как Центр Сертефикации) |
||
В контексте документа может иметь несколько возможных значений - как собственно центр выпуска сертификатов, так и сам корневой (или промежуточный сертификат) этого центра. По сути, сертификат СА, который используется для подписания клиентских и серверных сертификатом не только не является секретным, но наоборот должен быть доступен для доступа так как именно он используется для проверки валидности выпущенных сертификатов |
В контексте документа может иметь несколько возможных значений - как собственно центр выпуска сертификатов, так и сам корневой (или промежуточный сертификат) этого центра. По сути, сертификат СА, который используется для подписания клиентских и серверных сертификатом не только не является секретным, но наоборот должен быть доступен для доступа так как именно он используется для проверки валидности выпущенных сертификатов |
||
Строка 21: | Строка 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> |
||
+ | }} |
||
Строка 45: | Строка 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> |
||
В частных случаях можно упростить настройку, и вообще использовать 1 СА<br> |
В частных случаях можно упростить настройку, и вообще использовать 1 СА<br> |
||
− | Эта инсталляция подразумевает настойку PKI средней сложности |
+ | Эта инсталляция подразумевает настойку PKI средней сложности. |
<br> |
<br> |
||
+ | |||
=<code>k8s_pki_intermediate_ca_for_service_etcd/</code>= |
=<code>k8s_pki_intermediate_ca_for_service_etcd/</code>= |
||
Строка 58: | Строка 155: | ||
* для авторизации клиентов |
* для авторизации клиентов |
||
− | =<code>k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/</code> |
+ | =<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_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> |
||
Строка 73: | Строка 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> |
||
Строка 94: | Строка 202: | ||
=Полный список сертификатов с кратким описанием= |
=Полный список сертификатов с кратким описанием= |
||
+ | Это 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 |
||
Строка 105: | Строка 213: | ||
</PRE> |
</PRE> |
||
+ | Note: так как префикс <code>k8s_pki_intermediate_ca_for_service_</code> в именовании CA общий, то в таблице для удобства форматирования он опущен |
||
+ | |||
+ | |||
+ | ==<code>kube-apiserver</code>== |
||
{| class="wikitable sortable" |
{| class="wikitable sortable" |
||
− | |+ Сертификаты K8s |
+ | |+ Сертификаты 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> |
+ | || <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> |
||
Строка 163: | Строка 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> |
+ | || <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> |
||
Строка 232: | Строка 346: | ||
| <code>kube-apiserver</code> |
| <code>kube-apiserver</code> |
||
|| <code>--client-ca-file</code> |
|| <code>--client-ca-file</code> |
||
− | || <code>CA</code> <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> может проверять сертификаты клиентов но не может выписывать новые сертификаты, эта часть - за администратором системы. |
||
+ | |||
+ | <BR> |
||
+ | '''Именно с пмощью этого СА проверяются сертификаты как пользователей (если пользователи используют сертификаты) так и сервисов <code>kube-controller-manager</code>, <code>kube-proxy</code>, <code>kube-scheduler</code>, <code>kubelet</code>''' |
||
<BR>В случае PKI на основе <code>Vault</code> CA в любой момент можно скачать. |
<BR>В случае PKI на основе <code>Vault</code> CA в любой момент можно скачать. |
||
|| |
|| |
||
Строка 289: | Строка 407: | ||
| <code>kube-apiserver</code> |
| <code>kube-apiserver</code> |
||
|| <code>--kubelet-certificate-authority</code> |
|| <code>--kubelet-certificate-authority</code> |
||
− | || <code>CA</code><BR><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>) |
||
Строка 341: | Строка 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> |
+ | || <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> |
||
|| |
|| |
||
Строка 383: | Строка 503: | ||
</PRE> |
</PRE> |
||
|- |
|- |
||
+ | |} |
||
+ | ==<code>kube-controller-manager</code>== |
||
+ | {| class="wikitable sortable" |
||
− | |||
+ | |+ Сертификаты K8s <code>kube-controller-manager</code> |
||
− | |||
+ | |- |
||
− | |||
+ | ! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Тип сертификата (серверный/клиентский/CA) !! Назначение !! Subject и подробности |
||
− | |||
+ | |- |
||
− | |||
− | |||
− | |||
| <code>kube-controller-manager</code> |
| <code>kube-controller-manager</code> |
||
+ | || |
||
− | || <code>--tls-cert-file</code> <code>--tls-private-key-file</code> |
||
+ | <code>--tls-cert-file</code><BR> |
||
− | ||СА выпустивший сертификат |
||
+ | <code>--tls-private-key-file</code> |
||
− | ||Назначение |
||
+ | ||<code>kube_controller_manager_tls/</code> |
||
− | ||Subject и подлробности |
||
+ | || Серверный<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> |
||
+ | openssl s_client -connect kube-controller-manager.az1.k8s.cluster.home:10257 |
||
+ | </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> |
||
|- |
|- |
||
Строка 413: | Строка 588: | ||
| <code>kube-controller-manager</code> |
| <code>kube-controller-manager</code> |
||
|| --root-ca-file |
|| --root-ca-file |
||
+ | ||Root СА |
||
− | ||СА выпустивший сертификат |
||
+ | ||Не Серверный<BR>Не Клиентский<BR>'''CA''' |
||
− | ||Назначение |
||
+ | ||Этот СА которым подписаны сертификаты для <code>HTTPS/TLS</code> для <code>kube-api-server</code> и он используется для проверки серверных сертификатов. Обладая этим CA можно проверить что подключение происходит к правильному <code>kube-apiserver</code> |
||
− | ||Subject и подлробности |
||
− | | |
+ | || |
− | |||
− | |||
− | | <code>kube-controller-manager</code> |
||
− | || |
||
<PRE> |
<PRE> |
||
+ | openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem |
||
− | 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 |
||
</PRE> |
</PRE> |
||
+ | <PRE> |
||
− | ||СА выпустивший сертификат |
||
+ | Certificate: |
||
− | ||Назначение |
||
+ | Data: |
||
− | ||Subject и подлробности |
||
+ | 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 |
||
+ | </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> |
||
− | | <code>kube-proxy</code> |
||
+ | <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 |
||
− | ||СА выпустивший сертификат |
||
+ | 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> |
||
− | ||Subject и подлробности |
||
+ | Или посмотреть в файле (путь к файлу в параметрах сервиса) |
||
+ | <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> |
||
|- |
|- |
||
+ | |} |
||
+ | ==<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" |
||
− | | <code>kube-scheduler</code> |
||
+ | |+ Сертификаты K8s <code>kubelet</code> |
||
− | || Текст ячейки |
||
− | ||СА выпустивший сертификат |
||
− | ||Назначение |
||
− | ||Subject и подлробности |
||
|- |
|- |
||
+ | ! Сервис который использует этот сертификат !! Параметр сервиса !! СА выпустивший сертификат !! Тип сертификата (серверный/клиентский/CA) !! Назначение !! Subject и подробности |
||
− | |||
− | |||
− | |||
− | |||
− | | <code>kubelet</code> |
||
− | || Текст ячейки |
||
− | ||СА выпустивший сертификат |
||
− | ||Назначение |
||
− | ||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: |
||
− | | <code></code> |
||
+ | 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 |
||
− | ||Subject и подлробности |
||
+ | 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 |
||
+ | ... |
||
+ | </PRE> |
||
|- |
|- |
||
Строка 498: | Строка 769: | ||
+ | | <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> с одним из имен разрешенных для использования в сертификате. |
||
− | ||Назначение |
||
+ | || |
||
− | ||Subject и подлробности |
||
+ | Обратить внимание что в сертификате прописаны несколько возможных имен |
||
− | |} |
||
+ | * 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''' |
||
− | =TLS CA= |
||
+ | * IP Address:10.0.12.1 |
||
− | Для того что бы предоставлять API по https нужны следующие СА |
||
+ | Сертификат можно просмотреть: |
||
− | ==<code>kube-apiserver</code> TLS CA== |
||
− | Для обеспечения <code>https</code> доступа к API используются 2 параметра - файл сертефиката и файл ключа |
||
− | * <code>--tls-cert-file</code> |
||
− | * <code>--tls-private-key-file</code> |
||
− | Этот сертификат выпускается <code>k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/</code> |
||
− | <br> |
||
<PRE> |
<PRE> |
||
+ | openssl x509 -noout -text -in /etc/k8s/kubelet/certs/tls/kubelet-tls.pem |
||
− | netstat -ntpl| grep kube-api |
||
− | tcp 0 0 10.0.12.1:6443 0.0.0.0:* LISTEN 85224/kube-apiserve |
||
</PRE> |
</PRE> |
||
<PRE> |
<PRE> |
||
+ | Certificate: |
||
− | openssl s_client -connect 10.0.12.1:6443 |
||
+ | 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: |
||
... |
... |
||
− | |||
− | depth=2 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 |
||
− | verify return:1 |
||
− | depth=1 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 |
||
− | verify return:1 |
||
− | depth=0 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 |
||
− | verify return:1 |
||
</PRE> |
</PRE> |
||
+ | |- |
||
+ | |} |
||
− | ==<code>kube-controller-manager</code> TLS CA== |
||
− | * <code>--tls-cert-file</code> |
||
− | * <code>--tls-private-key-file</code> |
||
− | = |
+ | =Файлы <code>kubeconfig</code>= |
+ | Некоторые сервисы используют <code>kubeconfig</code> для авторизации у <code>kube-apiserver</code>, в том числе плюс-минус такой же конфиг используется для авторизации администратора |
||
− | --tls-cert-file |
||
+ | <br> |
||
− | --tls-private-key-file |
||
+ | ==Описание формата <code>kubeconfig</code>== |
||
+ | Разберем пример файла (для примера взят конфиг от <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> |
||
+ | ===clusters=== |
||
− | ==<code>kubelet</code> TLS CA== |
||
+ | В этой секции описываются кластера, а именно |
||
− | * <code>tlsCertFile</code> |
||
+ | * имя кластера |
||
− | * <code>tlsPrivateKeyFile</code> |
||
+ | <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=== |
||
− | This parameter should be set via the config file specified by the Kubelet's --config |
||
+ | В этой секции содержится описание пользователя, а именно: |
||
+ | * Имя пользователя |
||
+ | <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: |
||
− | kind: KubeletConfiguration |
||
+ | - context: |
||
− | apiVersion: kubelet.config.k8s.io/v1beta1 |
||
+ | cluster: kubernetes-the-hardest-way |
||
− | ... |
||
+ | user: system:node:worker01.az1.k8s.cluster.home |
||
− | tlsCertFile: "/etc/k8s/kubelet/tls/kubelet.az1.k8s.home.pem" |
||
+ | name: default |
||
− | tlsPrivateKeyFile: "/etc/k8s/kubelet/tls/kubelet.az1.k8s.home.key" |
||
− | authorizationMode: Node,RBAC |
||
</PRE> |
</PRE> |
||
+ | ===current-contex=== |
||
− | =Client CA= |
||
+ | Эта секция определяет какой контекст будет использоваться по-умолчанию |
||
− | * https://kubernetes.io/docs/setup/best-practices/certificates/ |
||
− | ==<code></code>== |
||
− | ==<code></code>== |
||
− | ==<code></code>== |
||
− | ==<code></code>== |
||
− | |||
− | =СА для TLS= |
||
− | Отдельный СА (промежуточный СА!) |
||
<br> |
<br> |
||
+ | В примере ниже используется по умолчанию контекст с именем <code>default</code>, и здесь слово '''default''' не имеет никакого магического значение - это просто имя контекста определенного в секции <code>contexts</code> и не более того |
||
− | Переменные вынесены в отдельный файл |
||
<PRE> |
<PRE> |
||
+ | current-context: default |
||
− | env |
||
</PRE> |
</PRE> |
||
+ | ==Общие части для всех kubeconfig== |
||
+ | ===clusters=== |
||
+ | Так-как это все <code>kubeconfig</code>для одного кластера то у всех их есть общая часть |
||
<PRE> |
<PRE> |
||
+ | clusters: |
||
− | export VAULT_ADDR=http://127.0.0.1:8200 |
||
+ | - cluster: |
||
− | export VAULT_TOKEN="s.Yb1J2VamFyYoav3VVE2YQQ88" |
||
+ | certificate-authority-data: LS0tLS1CRUdJ ... skipped long line ... |
||
− | export PKI_PATH="k8s_pki_intermediate_ca_for_service_kube_apiserver_tls" |
||
− | + | server: https://kube-apiserver.k8s.cluster.home:443 |
|
+ | name: kubernetes-the-hardest-way |
||
</PRE> |
</PRE> |
||
− | |||
− | ==Настройка СА== |
||
<PRE> |
<PRE> |
||
+ | clusters: |
||
− | #!/bin/bash |
||
+ | - cluster: |
||
− | |||
+ | certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem |
||
− | source ../env |
||
+ | server: https://kube-apiserver.k8s.cluster.home:443 |
||
− | |||
− | vault \ |
||
− | secrets \ |
||
− | enable \ |
||
− | -path=${PKI_PATH} \ |
||
− | -description="PKI Intermediate CA for K8S kube-apiserver API endpoints" \ |
||
− | -max-lease-ttl="175200h" \ |
||
− | pki |
||
</PRE> |
</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> |
<PRE> |
||
+ | users: |
||
− | #!/bin/bash |
||
+ | - name: some-name |
||
− | |||
+ | user: |
||
− | source ../env |
||
+ | client-certificate: some-cert.pem |
||
− | |||
+ | client-key: some-key.key |
||
− | vault \ |
||
− | write \ |
||
− | -format=json \ |
||
− | ${PKI_PATH}/intermediate/generate/exported \ |
||
− | common_name="Intermediate CA for service kube-api-server API endpoints" \ |
||
− | country="Ukraine" \ |
||
− | locality="Kharkov" \ |
||
− | street_address="Lui Pastera st. 322 app. 131" \ |
||
− | postal_code="61172" \ |
||
− | organization="K8s The Hardest Way Labs" \ |
||
− | ou="IT" \ |
||
− | ttl="175200h" > ${PKI_PATH}.json |
||
− | |||
− | |||
− | cat ${PKI_PATH}.json | jq -r '.data.csr' > ${PKI_PATH}_intermediate_ca.csr |
||
− | cat ${PKI_PATH}.json | jq -r '.data.private_key' > ${PKI_PATH}_intermediate_ca.key |
||
</PRE> |
</PRE> |
||
+ | ==Admin== |
||
<PRE> |
<PRE> |
||
+ | apiVersion: v1 |
||
− | #!/bin/bash |
||
+ | clusters: |
||
− | |||
+ | - cluster: |
||
− | source ../env |
||
+ | certificate-authority-data: LS0tLS1CRUdJ ... skipped long line ... |
||
− | |||
+ | server: https://kube-apiserver.k8s.cluster.home:443 |
||
− | vault \ |
||
+ | name: kubernetes-the-hardest-way |
||
− | write \ |
||
+ | contexts: |
||
− | -format=json \ |
||
+ | - context: |
||
− | k8s_pki_root_ca/root/sign-intermediate \ |
||
+ | cluster: kubernetes-the-hardest-way |
||
− | csr=@${PKI_PATH}_intermediate_ca.csr \ |
||
+ | user: admin |
||
− | country="Ukraine" \ |
||
+ | name: default |
||
− | locality="Kharkov" \ |
||
+ | current-context: default |
||
− | street_address="Lui Pastera st. 322 app. 131" \ |
||
+ | kind: Config |
||
− | postal_code="61172" \ |
||
+ | preferences: {} |
||
− | organization="K8s The Hardest Way Labs" \ |
||
+ | users: |
||
− | ou="IT" \ |
||
+ | - name: admin |
||
− | format=pem_bundle \ |
||
+ | user: |
||
− | ttl="175200h" > ${PKI_PATH}_intermediate_ca_pem_bundle.json |
||
+ | client-certificate-data: LS0tLS1CRUdJT ... skipped long line ... |
||
− | |||
+ | client-key-data: LS0tLS1CRUdJTiB ... skipped long line |
||
− | |||
− | cat ${PKI_PATH}_intermediate_ca_pem_bundle.json | jq -r '.data.certificate' > ${PKI_PATH}_intermediate_ca_pem.crt |
||
− | cat ${PKI_PATH}_intermediate_ca_pem_bundle.json | jq -r '.data.issuing_ca' > k8s_root_certificate.pem |
||
</PRE> |
</PRE> |
||
+ | Просмотр сертификата |
||
− | |||
<PRE> |
<PRE> |
||
+ | openssl x509 -noout -text -in admin.pem | grep "Subject:" |
||
− | #!/bin/bash |
||
− | |||
− | source ../env |
||
− | |||
− | openssl \ |
||
− | verify \ |
||
− | -verbose \ |
||
− | -CAfile k8s_root_certificate.pem \ |
||
− | ${PKI_PATH}_intermediate_ca_pem.crt |
||
</PRE> |
</PRE> |
||
+ | Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:masters, OU = system, CN = admin |
||
− | |||
+ | </PRE> |
||
+ | * группа <code> O = system:masters</code> |
||
+ | * Пользователь <code>CN = admin</code> |
||
+ | * Права назначаются СlusterRoleBinding на группу: |
||
<PRE> |
<PRE> |
||
+ | kind: Group |
||
− | #!/bin/bash |
||
+ | name: system:masters |
||
− | |||
− | source ../env |
||
− | |||
− | vault \ |
||
− | write \ |
||
− | ${PKI_PATH}/intermediate/set-signed \ |
||
− | certificate=@${PKI_PATH}_intermediate_ca_pem.crt \ |
||
− | key=@${PKI_PATH}_intermediate_ca.key |
||
</PRE> |
</PRE> |
||
+ | '''Имя ClusterRoleBinding получено методом полного перебора что бы понять в каком из них происходит назначение прав на группу <code>system:masters</code>. Для остальных групп - аналогично, хотя часто имя binding совпадает с названием группы. ''' |
||
− | ==Права, пользователи, роли== |
||
+ | <BR> |
||
− | Далее назначить права на пользователей для каждого экземпляра сервера |
||
+ | Полный вывод: |
||
<PRE> |
<PRE> |
||
+ | kubectl get clusterrolebinding cluster-admin -o yaml |
||
− | #!/bin/bash |
||
+ | </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: 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> |
||
+ | ==<code>kube-controller-manager</code>== |
||
− | source ../env |
||
+ | <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 |
||
− | N='kube-apiserver' |
||
+ | contexts: |
||
− | for AZ in $(seq 1 3); |
||
+ | - context: |
||
− | do |
||
+ | cluster: kubernetes-the-hardest-way |
||
− | DOMAIN="${N}.az${AZ}.k8s.cluster.home" |
||
+ | user: system:kube-controller-manager |
||
− | BALANCER_DOMAIN="${N}.k8s.cluster.home" |
||
+ | name: default |
||
− | NAME_SERVER="${DOMAIN}-server" |
||
+ | current-context: default |
||
− | NAME_CLIENT="${DOMAIN}-client" |
||
+ | kind: Config |
||
− | |||
+ | preferences: {} |
||
− | |||
+ | users: |
||
− | vault \ |
||
+ | - name: system:kube-controller-manager |
||
− | write \ |
||
+ | user: |
||
− | ${PKI_PATH}/roles/${NAME_SERVER}-role \ |
||
+ | client-certificate: /etc/k8s/kube-controller-manager/certs/client_auth/kube-apiserver-client_auth.pem |
||
− | country="Ukraine" \ |
||
+ | client-key: /etc/k8s/kube-controller-manager/certs/client_auth/kube-apiserver-client_auth.key |
||
− | locality="Kharkov" \ |
||
+ | </PRE> |
||
− | street_address="Lui Pastera st 322 app. 311"\ |
||
+ | Аналогично админу - можно проверить пользователя, группу и права |
||
− | postal_code="61172" \ |
||
+ | <PRE> |
||
− | organization="Home Network" \ |
||
+ | openssl x509 -noout -text -in /etc/k8s/kube-controller-manager/certs/client_auth/kube-apiserver-client_auth.pem | grep "Subject:" |
||
− | ou="IT" \ |
||
+ | </PRE> |
||
− | allowed_domains="${DOMAIN},${BALANCER_DOMAIN}" \ |
||
+ | <PRE> |
||
− | allow_subdomains=false \ |
||
+ | Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:kube-controller-manager, OU = system, CN = system:kube-controller-manager |
||
− | max_ttl="87600h" \ |
||
+ | </PRE> |
||
− | key_bits="2048" \ |
||
+ | <PRE> |
||
− | key_type="rsa" \ |
||
+ | kubectl get clusterrolebinding system:kube-controller-manager -o yaml |
||
− | allow_any_name=false \ |
||
+ | </PRE> |
||
− | allow_bare_domains=true \ |
||
+ | <PRE> |
||
− | allow_glob_domain=false \ |
||
+ | apiVersion: rbac.authorization.k8s.io/v1 |
||
− | allow_ip_sans=true \ |
||
+ | kind: ClusterRoleBinding |
||
− | allow_localhost=false \ |
||
+ | metadata: |
||
− | client_flag=true \ |
||
+ | annotations: |
||
− | server_flag=true \ |
||
+ | rbac.authorization.kubernetes.io/autoupdate: "true" |
||
− | enforce_hostnames=true \ |
||
+ | creationTimestamp: "2022-11-08T09:41:39Z" |
||
− | key_usage="DigitalSignature,KeyEncipherment" \ |
||
+ | labels: |
||
− | ext_key_usage="ServerAuth" \ |
||
+ | kubernetes.io/bootstrapping: rbac-defaults |
||
− | require_cn=true |
||
+ | name: system:kube-controller-manager |
||
− | |||
+ | resourceVersion: "151" |
||
− | vault \ |
||
+ | uid: 53b7d64d-f3f6-49bc-8954-6c8eea6fb444 |
||
− | write \ |
||
+ | roleRef: |
||
− | ${PKI_PATH}/roles/${NAME_CLIENT}-role \ |
||
+ | apiGroup: rbac.authorization.k8s.io |
||
− | country="Ukraine" \ |
||
+ | kind: ClusterRole |
||
− | locality="Kharkov" \ |
||
+ | name: system:kube-controller-manager |
||
− | street_address="Lui Pastera st 322 app. 311"\ |
||
+ | subjects: |
||
− | postal_code="61172" \ |
||
+ | - apiGroup: rbac.authorization.k8s.io |
||
− | organization="Home Network" \ |
||
+ | kind: User |
||
− | ou="IT" \ |
||
+ | name: system:kube-controller-manager |
||
− | allow_subdomains=false \ |
||
− | max_ttl="87600h" \ |
||
− | key_bits="2048" \ |
||
− | key_type="rsa" \ |
||
− | allow_any_name=true \ |
||
− | allow_bare_domains=true \ |
||
− | allow_glob_domain=false \ |
||
− | allow_ip_sans=true \ |
||
− | allow_localhost=false \ |
||
− | client_flag=true \ |
||
− | server_flag=false \ |
||
− | enforce_hostnames=true \ |
||
− | key_usage="DigitalSignature,KeyEncipherment" \ |
||
− | ext_key_usage="ClientAuth" \ |
||
− | require_cn=true |
||
− | done |
||
</PRE> |
</PRE> |
||
+ | ==<code>kube-proxy</code>== |
||
<PRE> |
<PRE> |
||
+ | apiVersion: v1 |
||
− | #!/bin/bash |
||
+ | 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: |
||
− | source ../env |
||
+ | - context: |
||
− | |||
+ | cluster: kubernetes-the-hardest-way |
||
− | N='kube-apiserver' |
||
+ | user: system:kube-proxy |
||
− | for AZ in $(seq 1 3); |
||
+ | name: default |
||
− | do |
||
+ | current-context: default |
||
− | DOMAIN="${N}.az${AZ}.k8s.cluster.home" |
||
− | NAME_SERVER="${DOMAIN}-server" |
||
− | NAME_CLIENT="${DOMAIN}-client" |
||
− | |||
− | cat << EOF > ${NAME_SERVER}-policy.hlc |
||
− | path "${PKI_PATH}/issue/${NAME_SERVER}-role" |
||
− | { |
||
− | capabilities = ["read", "create", "list", "update"] |
||
− | } |
||
− | EOF |
||
− | |||
− | vault \ |
||
− | policy \ |
||
− | write \ |
||
− | ${NAME_SERVER}-policy \ |
||
− | ${NAME_SERVER}-policy.hlc |
||
− | vault \ |
||
− | write \ |
||
− | auth/userpass/users/${NAME_SERVER}-user \ |
||
− | password=${NAME_SERVER}-password \ |
||
− | policies=" ${NAME_SERVER}-policy,default" |
||
− | |||
− | |||
− | |||
− | cat << EOF > ${NAME_CLIENT}-policy.hlc |
||
− | path "${PKI_NAME}/issue/${NAME_CLIENT}-role" |
||
− | { |
||
− | capabilities = ["read", "create", "list", "update"] |
||
− | } |
||
− | EOF |
||
+ | kind: Config |
||
− | vault \ |
||
+ | preferences: {} |
||
− | policy \ |
||
+ | users: |
||
− | write \ |
||
+ | - name: system:kube-proxy |
||
− | ${NAME_CLIENT}-policy \ |
||
+ | user: |
||
− | ${NAME_CLIENT}-policy.hlc |
||
+ | client-certificate: /etc/k8s/kube-proxy/certs/client_auth/kube-apiserver-client_auth.pem |
||
− | vault \ |
||
+ | client-key: /etc/k8s/kube-proxy/certs/client_auth/kube-apiserver-client_auth.key |
||
− | write \ |
||
− | auth/userpass/users/${NAME_CLIENT}-user \ |
||
− | password=${NAME_CLIENT}-password \ |
||
− | policies=" ${NAME_CLIENT}-policy,default" |
||
− | |||
− | |||
− | done |
||
</PRE> |
</PRE> |
||
+ | Аналогично админу - можно проверить пользователя, группу и права |
||
<PRE> |
<PRE> |
||
+ | openssl x509 -noout -text -in /etc/k8s/kube-proxy/certs/client_auth/kube-apiserver-client_auth.pem | grep "Subject:" |
||
− | #!/bin/bash |
||
+ | </PRE> |
||
− | |||
+ | <PRE> |
||
− | source ../env |
||
+ | Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:node-proxier, OU = system, CN = system:kube-proxy |
||
+ | </PRE> |
||
+ | <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> |
||
+ | ==<code>kube-scheduler</code>== |
||
− | echo "---------ROLES---------------------" |
||
+ | <PRE> |
||
− | vault \ |
||
+ | apiVersion: v1 |
||
− | list \ |
||
+ | clusters: |
||
− | ${PKI_PATH}/roles |
||
+ | - cluster: |
||
− | echo "---------USERS---------------------" |
||
+ | certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem |
||
− | vault \ |
||
+ | server: https://kube-apiserver.k8s.cluster.home:443 |
||
− | list \ |
||
+ | name: kubernetes-the-hardest-way |
||
− | auth/userpass/users |
||
+ | contexts: |
||
− | echo "------------------------------" |
||
+ | - context: |
||
− | |||
+ | cluster: kubernetes-the-hardest-way |
||
− | |||
+ | user: system:kube-scheduler |
||
− | for AZ in $(seq 1 3); |
||
+ | name: default |
||
− | do |
||
+ | current-context: default |
||
− | echo "------ AZ ${AZ} -----" |
||
+ | kind: Config |
||
− | DOMAIN="${N}.az${AZ}.k8s.cluster.home" |
||
+ | preferences: {} |
||
− | NAME_SERVER="${DOMAIN}-server" |
||
+ | users: |
||
− | NAME_CLIENT="${DOMAIN}-client" |
||
+ | - name: system:kube-scheduler |
||
− | |||
+ | user: |
||
− | vault \ |
||
+ | client-certificate: /etc/k8s/kube-scheduler/certs/client_auth/kube-apiserver-client_auth.pem |
||
− | policy \ |
||
+ | client-key: /etc/k8s/kube-scheduler/certs/client_auth/kube-apiserver-client_auth.key |
||
− | read \ |
||
− | ${NAME_SERVER}-policy |
||
− | |||
− | vault \ |
||
− | policy \ |
||
− | read \ |
||
− | ${NAME_CLIENT}-policy |
||
− | |||
− | vault \ |
||
− | read \ |
||
− | auth/userpass/users/${NAME_SERVER}-user |
||
− | vault \ |
||
− | read \ |
||
− | auth/userpass/users/${NAME_SERVER}-user |
||
− | |||
− | done |
||
</PRE> |
</PRE> |
||
− | |||
− | ==Пример получения сертефикатов== |
||
− | на конечных нодах используя имя пользователя и пароль а так же переменную AZ определнную на нодах индивидуально ([[Kubernetes_the_hard_way_kube_apiserver#--tls-cert-file_--tls-private-key-file|Сертефикаты для <code>kube-apiserver</code> <code>--tls-cert-file</code> и <code>--tls-private-key-file</code>]]) |
||
<PRE> |
<PRE> |
||
+ | openssl x509 -noout -text -in /etc/k8s/kube-scheduler/certs/client_auth/kube-apiserver-client_auth.pem | grep "Subject:" |
||
− | #!/bin/bash |
||
+ | </PRE> |
||
− | |||
+ | <PRE> |
||
− | set -eu${DEBUG:+x} |
||
+ | Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:kube-scheduler, OU = system, CN = system:kube-scheduler |
||
− | |||
+ | </PRE> |
||
− | PKI_NAME="k8s_pki_intermediate_ca_for_service_kube_apiserver_tls" |
||
− | CERTS_PATH="/etc/k8s/kube-apiserver/certs/tls" |
||
− | mkdir -p ${CERTS_PATH} |
||
− | |||
− | N='kube-apiserver' |
||
− | #AZ=1 |
||
− | DOMAIN="${N}.az${AZ}.k8s.cluster.home" |
||
− | NAME_SERVER="${DOMAIN}-server" |
||
− | NAME_CLIENT="${DOMAIN}-client" |
||
− | BALANCER_DOMAIN="${N}.k8s.cluster.home" |
||
− | IP="10.0.${AZ}2.1" |
||
− | vault \ |
||
− | login \ |
||
− | -method=userpass \ |
||
− | username="${NAME_SERVER}-user" \ |
||
− | password="${NAME_SERVER}-password" |
||
+ | <PRE> |
||
− | |||
+ | kubectl get clusterrolebinding system:kube-scheduler -o yaml |
||
− | DATE=$(date +%Y%m%dT%H%M) |
||
+ | </PRE> |
||
− | USERNAME="${N}-${AZ}-tls" |
||
+ | <PRE> |
||
− | |||
+ | apiVersion: rbac.authorization.k8s.io/v1 |
||
− | echo "========" |
||
+ | kind: ClusterRoleBinding |
||
− | vault \ |
||
+ | metadata: |
||
− | write \ |
||
+ | annotations: |
||
− | -format=json \ |
||
+ | rbac.authorization.kubernetes.io/autoupdate: "true" |
||
− | ${PKI_NAME}/issue/${NAME_SERVER}-role \ |
||
+ | creationTimestamp: "2022-11-08T09:41:39Z" |
||
− | common_name="${DOMAIN}" \ |
||
+ | labels: |
||
− | alt_names="${DOMAIN},${BALANCER_DOMAIN}" \ |
||
+ | kubernetes.io/bootstrapping: rbac-defaults |
||
− | ip_sans="${IP}" \ |
||
+ | name: system:kube-scheduler |
||
− | ca=false \ |
||
+ | resourceVersion: "153" |
||
− | ttl="43800h" \ |
||
+ | uid: 4a50831a-e5f8-4a77-8aef-cea46ac24231 |
||
− | > ${CERTS_PATH}/${USERNAME}.crt.json |
||
+ | roleRef: |
||
− | |||
+ | apiGroup: rbac.authorization.k8s.io |
||
− | cat \ |
||
+ | kind: ClusterRole |
||
− | ${CERTS_PATH}/${USERNAME}.crt.json \ |
||
+ | name: system:kube-scheduler |
||
− | | jq -r '.data.private_key' > ${CERTS_PATH}/${USERNAME}-${DATE}.key |
||
+ | subjects: |
||
− | |||
+ | - apiGroup: rbac.authorization.k8s.io |
||
− | cat \ |
||
+ | kind: User |
||
− | ${CERTS_PATH}/${USERNAME}.crt.json \ |
||
+ | name: system:kube-scheduler |
||
− | | jq -r '.data.certificate' > ${CERTS_PATH}/${USERNAME}-${DATE}.pem |
||
− | |||
− | cat \ |
||
− | ${CERTS_PATH}/${USERNAME}.crt.json \ |
||
− | | jq -r '.data.ca_chain[]' >> ${CERTS_PATH}/${USERNAME}-${DATE}.pem |
||
− | |||
− | ln -sf ${CERTS_PATH}/${USERNAME}-${DATE}.key ${CERTS_PATH}/${N}-tls.key |
||
− | ln -sf ${CERTS_PATH}/${USERNAME}-${DATE}.pem ${CERTS_PATH}/${N}-tls.pem |
||
</PRE> |
</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> |
||
+ | 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> |
Текущая версия на 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