Vault PKI Intermediate CAs for ALL SERVICES Kubernetes the hard way v2
Эта страница - часть большой статьи про 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) (с логином и паролем, который выдается ) (тому сервису которому нужен сертификат)
Например
- Cервису
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) и при необходимости перевыпустить его. - Автоматизация перевыпуска сертификатов - дело будущей настройки сервисов и будет описана в других разделах
Создание СА для работы кластера 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
), а второй используется для обеспечения https
- У
kube-apiserver
есть настройка --kubelet-certificate-authority
- это файл СА k8s_pki_intermediate_ca_for_service_kubelet_tls/
(другими словами, это тот СА который выписал серверный сертификат для обеспечения HTTPS/TLS
API kubelet
( Порт 10250).
Ghjcvjnhtnm tuj vj;yj
openssl s_client -connect 127.0.0.1:10250
таким образом kube-apiserver
может
точно знать что он обращается к нужному kubelet
, так как его серверный сертефикат подписан этим СА
--kubelet-client-certificate
--kubelet-client-key
содрежат сертификат, выписанный помощью СА k8s_pki_intermediate_ca_for_service_kubelet_client_auth/
и содержат имя пользователя и группу с которыми kube-apiserver авторизуется
у kubelet
Например: O = system:masters
, OU = system
, CN = kube-apiserver-to-kubelet
При этом по-умолчанию соответствующие ClustetRoleBinding
отсутствуют, и перед подключением kubelet
их требуется создать дополнительно. (эта часть настройки выполняется при конфигурировании kube-apiserver
k8s_pki_intermediate_ca_for_service_kubelet_tls/
- используется для обеспечения https, серверные сетефикаты
k8s_pki_root_ca/
k8s_pki_root_ca/
- это корневой СА которым подписаны все промежуточные СА, и его сертификат СА обязательно требуется распространить по всем хостам так как он является полностью доверенным (в пределах этой инсталляции, конечно)
Полный список сертификатов с кратким описанием
Это CA (в VAULT
, c именами и описаниями) которые используются для выпуска сертификатов для k8s)
k8s_pki_intermediate_ca_for_service_etcd/ pki pki_13a87e77 PKI Intermediate CA for ETCd service
k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/ pki pki_622072da PKI Intermediate CA for K8S: kube-apiserver CLIENT_AUTH
k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/ pki pki_d8737474 PKI Intermediate CA for K8S: kube-apiserver TLS
k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/ pki pki_34a63553 PKI Intermediate CA for K8S: kube-controller-manager TLS
k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/ pki pki_5b5f53f5 PKI Intermediate CA for K8S: kube-scheduler TLS
k8s_pki_intermediate_ca_for_service_kubelet_client_auth/ pki pki_4f1df8fd PKI Intermediate CA for K8S: kubelet CLIENT_AUTH
k8s_pki_intermediate_ca_for_service_kubelet_tls/ pki pki_47e7182a PKI Intermediate CA for K8S: kubelet TLS
Note: так как префикс k8s_pki_intermediate_ca_for_service_
в именовании CA общий, то в таблице для удобства форматирования он опущен
kube-apiserver
Сертификаты K8s kube-apiserver
Сервис который использует этот сертификат
Параметр сервиса
СА выпустивший сертификат
Тип сертификата (серверный/клиентский/CA)
Назначение
Subject и подробности
kube-apiserver
--etcd-certfile
--etcd-keyfile
etcd
Клиентский
TLS Web Client
Authentication
Авторизация в etcd
. В зависимости от настроек содержит имя пользователя
если etcd настроен на такой тип авторизации, используется именно такой способ: (etcd
: авторизация с использованием сертификатов)
openssl x509 -noout -text -in /etc/k8s/kube-apiserver/certs/etcd/kube-apiserver.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
56:ce:57:67:7d:9b:54:76:6d:60:51:4a:0c:09:c7:11:ac:f1:95:3b
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, postalCode = 61172, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service ETCd
Validity
Not Before: Oct 17 15:23:37 2022 GMT
Not After : Oct 16 15:24:04 2027 GMT
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st 322 app. 311, postalCode = 61172, O = Home Network, OU = IT, CN = kube-apiserver-1
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Subject Key Identifier:
F8:E5:28:79:2F:4E:99:EA:BE:43:B7:CA:6C:1B:20:65:E6:0B:B3:72
X509v3 Authority Key Identifier:
60:41:31:79:58:90:A9:63:62:C2:26:FD:8F:02:B6:07:1A:1D:5C:50
Authority Information Access:
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_etcd/ca
X509v3 Subject Alternative Name:
DNS:kube-apiserver-1
X509v3 CRL Distribution Points:
Full Name:
URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_etcd/crl
kube-apiserver
--tls-cert-file
--tls-private-key-file
kube_apiserver_tls/
Серверный
TLS Web Server
Authentication
HTTPS
для API
Можно получить netstat -ntpl | grep kube-api
tcp 0 0 10.0.12.1:6443 0.0.0.0:* LISTEN 85224/kube-apiserve
Или взять из параметров kube-apiserver
Обратить внимание - в Alt Names прописан как основной домен (kube-apiserver.az1.k8s.cluster.home), так и домен балансера (kube-apiserver.k8s.cluster.home) а так же адреса по которым может быть доступен сервис. Адрес 10.80.0.1 указывается в настройках kube-apiserver
- DNS:kube-apiserver.az1.k8s.cluster.home
- DNS:kube-apiserver.k8s.cluster.home
- DNS:kubernetes
- DNS:kubernetes.cluster.home
- IP Address:10.0.12.1
- IP Address:10.80.0.1
- IP Address:127.0.0.1
openssl x509 -noout -text -in /etc/k8s/kube-apiserver/certs/tls/kube-apiserver-tls.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
71:a8:93:84:83:df:af:ba:78:df:63:3d:fe:4d:7f:f4:22:26:23:24
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-apiserver TLS
Validity
Not Before: Nov 14 08:59:08 2022 GMT
Not After : Nov 13 08:59:35 2027 GMT
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-apiserver.az1.k8s.cluster.home
Subject Public Key Info:
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Key Identifier:
E0:69:16:9A:99:A8:E6:95:AB:2B:2D:BC:58:CF:5C:E0:61:BF:10:51
X509v3 Authority Key Identifier:
22:7D:70:47:DB:79:ED:91:79:B3:51:0E:23:5F:32:B9:37:01:8D:C1
Authority Information Access:
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/ca
X509v3 Subject Alternative Name:
DNS:kube-apiserver.az1.k8s.cluster.home, DNS:kube-apiserver.k8s.cluster.home, DNS:kubernetes, DNS:kubernetes.cluster.home, IP Address:10.0.12.1, IP Address:10.80.0.1, IP Address:127.0.0.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/crl
kube-apiserver
--client-ca-file
CA
kube_apiserver_client_auth/
Не серверный
Не клиентский
CA
Это СА который используется для проверки сертификатов, с которыми клиенты (другие сервисы или пользователи) подключаются к kube-apiserver
.
Важно, что ключ от этого сертификата в настройках kube-apiserver
не участвует.
Это означает что kube-apiserver
может проверять сертификаты клиентов но не может выписывать новые сертификаты, эта часть - за администратором системы.
Именно с пмощью этого СА проверяются сертификаты как пользователей (если пользователи используют сертификаты) так и сервисов kube-controller-manager
, kube-proxy
, kube-scheduler
, kubelet
В случае PKI на основе Vault
CA в любой момент можно скачать.
openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
1a:ba:2f:66:84:5f:65:d4:cf:65:e2:d8:86:6a:a5:22:fd:57:8c:2b
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
Validity
Not Before: Nov 5 10:21:06 2022 GMT
Not After : Oct 31 10:21:36 2042 GMT
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, CN = Intermediate CA for service kube-apiserver CLIENT_AUTH
Subject Public Key Info:
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
2F:8E:7A:14:33:0D:E1:66:69:81:85:F5:C5:EC:09:3E:89:E1:B7:DF
X509v3 Authority Key Identifier:
02:F8:85:2B:75:F8:E1:1C:69:28:30:32:21:2D:86:71:AF:AB:EC:3C
Authority Information Access:
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_root_ca/ca
X509v3 CRL Distribution Points:
Full Name:
URI:http://vault.home:8200/v1/k8s_pki_root_ca/crl
kube-apiserver
--kubelet-certificate-authority
CA
kubelet_tls
Не серверный
Не клиентский
CA
Это CA
используется для того, что бы проверить сертификат kubelet
, и быть уверенным что подключение к правильному kubelet
Этим же СА подписываются сертификаты kubelet
для TLS
(конфигурация kubelet
)
/etc/k8s/kubelet/kubelet-config.yaml
tlsCertFile: "/etc/k8s/kubelet/certs/tls/kubelet-tls.pem"
tlsPrivateKeyFile: "/etc/k8s/kubelet/certs/tls/kubelet-tls.key"
openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kubelet_tls.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
33:04:63:a1:86:f2:80:bd:96:5e:10:46:ae:d5:c8:28:89:d0:74:34
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
Validity
Not Before: Nov 10 14:11:32 2022 GMT
Not After : Nov 5 14:12:02 2042 GMT
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kubelet TLS
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
F1:9C:3B:FB:01:4E:9A:3F:F5:E8:28:CE:99:60:9F:E3:5E:51:DA:C8
X509v3 Authority Key Identifier:
02:F8:85:2B:75:F8:E1:1C:69:28:30:32:21:2D:86:71:AF:AB:EC:3C
Authority Information Access:
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_root_ca/ca
X509v3 CRL Distribution Points:
Full Name:
URI:http://vault.home:8200/v1/k8s_pki_root_ca/crl
kube-apiserver
--kubelet-client-certificate
--kubelet-client-key
kubelet_client_auth/
Клиентский
TLS Web Clien
Authentication
Это сертификат используется kube-apiserver
что бы авторизоваться у kubelet
, это нужно что бы kubelet
мог быть уверен что к нему пришел доверенный kube-apiserver
Обратить внимание на CN = kube-apiserver-to-kubelet
- для этого пользователя потребуется создать отдельный ClusterRoleBinding
, по-умолчанию его нет. Естественно, что для своих ролей имена можно использовать любые, kube-apiserver-to-kubelet
это текстовый идентификатор, который можно назначить по своему усмотрению, но, одинаковый как в сертификате так и в ClusterRoleBinding
openssl x509 -noout -text -in /etc/k8s/kube-apiserver/certs/client_auth/kubelet-client_auth.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
28:07:04:c7:ce:4a:6e:29:fc:f7:c9:60:00:57:2a:9c:16:ca:53:8f
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, CN = Intermediate CA for service kubelet CLIENT_AUTH
Validity
Not Before: Nov 13 14:43:03 2022 GMT
Not After : Nov 12 14:43:31 2027 GMT
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = system:masters, OU = system, CN = kube-apiserver-to-kubelet
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Subject Key Identifier:
22:7C:92:2B:A3:5F:53:0F:B5:7A:F2:84:FA:55:C9:51:DD:33:78:E8
X509v3 Authority Key Identifier:
50:35:A5:C5:B4:C6:FC:65:04:08:76:F7:FB:56:D3:76:6D:96:36:2F
Authority Information Access:
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kubelet_client_auth/ca
X509v3 Subject Alternative Name:
DNS:kube-apiserver-to-kubelet
X509v3 CRL Distribution Points:
Full Name:
URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kubelet_client_auth/crl
kube-controller-manager
Сертификаты K8s kube-controller-manager
Сервис который использует этот сертификат
Параметр сервиса
СА выпустивший сертификат
Тип сертификата (серверный/клиентский/CA)
Назначение
Subject и подробности
kube-controller-manager
--tls-cert-file
--tls-private-key-file
kube_controller_manager_tls/
Серверный
TLS Web Server
Authentication
kube-controller-manager
имеет свой API (по умолчанию - на порту 10257), в котором есть как минимум такие endpoints: /healthz, /readyz, /livez, /metrics.
Этот сертификат служит для организации TLS/HTTPS
для этого API
Для разрешения доступа без авторизации служит параметр --authorization-always-allow-paths=/healthz,/readyz,/livez,/metrics, где перечислаются endpoints к которым можно получить доступ.
Получить этот сертификат можно непосредственно подключившись к порту
openssl s_client -connect kube-controller-manager.az1.k8s.cluster.home:10257
subject=C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-controller-manager.az1.k8s.cluster.home
issuer=C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-controller-manager TLS
Или в соответствующем файле (путь - в конфиге сервиса)
openssl x509 -noout -text -in kube-controller-manager-tls.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
68:35:c6:9e:d5:7d:c6:c8:ff:64:03:e7:fd:d8:c0:03:ff:ee:ec:50
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-controller-manager TLS
Validity
Not Before: Nov 10 17:18:43 2022 GMT
Not After : Nov 9 17:19:11 2027 GMT
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-controller-manager.az1.k8s.cluster.home
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Key Identifier:
7A:16:23:C5:0F:42:C2:D2:F2:FD:4C:2F:98:88:62:4D:C7:C6:E0:2A
X509v3 Authority Key Identifier:
3A:B0:CE:B4:3E:05:3F:7C:5F:87:24:BA:89:99:03:C6:9F:4C:2E:B1
Authority Information Access:
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/ca
X509v3 Subject Alternative Name:
DNS:kube-controller-manager.az1.k8s.cluster.home, DNS:kube-controller-manager.k8s.cluster.home, IP Address:10.0.12.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/crl
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
...
kube-controller-manager
--root-ca-file
Root СА
Не Серверный
Не Клиентский
CA
Этот СА которым подписаны сертификаты для HTTPS/TLS
для kube-api-server
и он используется для проверки серверных сертификатов. Обладая этим CA можно проверить что подключение происходит к правильному kube-apiserver
openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0c:8b:42:a7:b4:5a:56:0e:b6:72:d0:40:03:70:5c:19:49:03:43:90
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
Validity
Not Before: Nov 10 14:09:38 2022 GMT
Not After : Nov 5 14:10:08 2042 GMT
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-apiserver TLS
kube-proxy
Для kube-proxy
за исключением kubeconfig
сертификаты не используются
kube-scheduler
Сертификаты K8s kube-scheduler
Сервис который использует этот сертификат
Параметр сервиса
СА выпустивший сертификат
Тип сертификата (серверный/клиентский/CA)
Назначение
Subject и подробности
kube-scheduler
--tls-cert-file
--tls-private-key-file
kube_scheduler_tls
Серверный
TLS Web Server
Authentication
kube-scheduler
имеет свой API (по умолчанию - на порту 10259), в котором есть как минимум такие endpoints: /healthz, /readyz, /livez, /metrics.
Этот сертификат служит для организации TLS/HTTPS
для этого API
Для разрешения доступа без авторизации служит параметр --authorization-always-allow-paths=/healthz,/readyz,/livez,/metrics, где перечислаются endpoints к которым можно получить доступ.
Сертификат можно просмотреть:
openssl s_client -connect kube-scheduler.az1.k8s.cluster.home:10259
subject=C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-scheduler.az1.k8s.cluster.home
issuer=C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-scheduler TLS
Или посмотреть в файле (путь к файлу в параметрах сервиса)
openssl x509 -noout -text -in kube-scheduler-tls.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
69:35:40:e1:3d:40:4f:f4:f4:0e:a7:a8:6b:cf:ab:5e:78:fd:76:e4
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kube-scheduler TLS
Validity
Not Before: Nov 10 17:43:55 2022 GMT
Not After : Nov 9 17:44:24 2027 GMT
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kube-scheduler.az1.k8s.cluster.home
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Key Identifier:
1E:54:7A:95:6C:DF:B4:99:1E:52:AC:33:42:E4:F0:FC:0C:64:55:A0
X509v3 Authority Key Identifier:
89:20:99:22:3A:5F:FB:50:26:01:42:BD:36:B6:F6:F3:B7:E4:51:A9
Authority Information Access:
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/ca
X509v3 Subject Alternative Name:
DNS:kube-scheduler.az1.k8s.cluster.home, DNS:kube-scheduler.k8s.cluster.home, IP Address:10.0.12.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/crl
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
...
kubelet
Для kubelet
сертификаты указываются в файле, определенном в параметре --config=/etc/k8s/kubelet/kubelet-config.yaml
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
anonymous:
enabled: false
webhook:
enabled: true
x509:
clientCAFile: "/etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kubelet_client_auth.pem"
authorization:
mode: Webhook
clusterDomain: "cluster.home"
clusterDNS:
- "10.80.0.10"
resolvConf: "/run/systemd/resolve/resolv.conf"
runtimeRequestTimeout: "15m"
tlsCertFile: "/etc/k8s/kubelet/certs/tls/kubelet-tls.pem"
tlsPrivateKeyFile: "/etc/k8s/kubelet/certs/tls/kubelet-tls.key"
authorizationMode: Node,RBAC
Сертификаты K8s kubelet
Сервис который использует этот сертификат
Параметр сервиса
СА выпустивший сертификат
Тип сертификата (серверный/клиентский/CA)
Назначение
Subject и подробности
kubelet
clientCAFile
Root CA (другими словами этот СА подписан корневым СА, а сам является промежуточным СА)
Не серверный
Не клиентский
СА
Предназначен для проверки сертификатов с которыми подключаются клиенты (насколько я знаю это только kube-apiserver
, в его параметрах это --kubelet-client-certificate
и
--kubelet-client-key
.
Сертификат можно просмотреть:
openssl x509 -noout -text -in /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kubelet_client_auth.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
6e:c2:5c:3f:d0:0d:de:a9:bc:8c:2f:78:39:b9:ce:c6:c4:0f:ce:86
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = Ukraine, L = Kharkov, street = app. 131 + street = Lui Pastera St. 322, postalCode = 61172, O = Home Network, OU = IT, CN = Root Certificate Authority for Home Network v2
Validity
Not Before: Nov 4 09:26:50 2022 GMT
Not After : Oct 30 09:27:20 2042 GMT
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, CN = Intermediate CA for service kubelet CLIENT_AUTH
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
50:35:A5:C5:B4:C6:FC:65:04:08:76:F7:FB:56:D3:76:6D:96:36:2F
X509v3 Authority Key Identifier:
02:F8:85:2B:75:F8:E1:1C:69:28:30:32:21:2D:86:71:AF:AB:EC:3C
Authority Information Access:
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_root_ca/ca
X509v3 CRL Distribution Points:
Full Name:
URI:http://vault.home:8200/v1/k8s_pki_root_ca/crl
...
kubelet
tlsCertFile
, tlsPrivateKeyFile
kubelet_tls
Серверный
TLS Web Server
Authentication
Используется для HTTP/TLS
для API kubelet
(к которому подключается kube-apiserver
, важный параметр - kubelet
должен регистрироваться в kube-apiserver
с одним из имен разрешенных для использования в сертификате.
Обратить внимание что в сертификате прописаны несколько возможных имен
- DNS:kubelet.az1.k8s.cluster.home
- DNS:worker01.az1.k8s.cluster.home - используется как основное, и указано в параметрах
kubelet
: --hostname-override=${KUBELET_HOSTNAME_OVERRIDE}
В примере это worker01.az1.k8s.cluster.home
- IP Address:10.0.12.1
Сертификат можно просмотреть:
openssl x509 -noout -text -in /etc/k8s/kubelet/certs/tls/kubelet-tls.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
18:6e:c4:32:a9:b7:ba:44:55:0d:52:df:d3:fb:e4:75:f0:29:7b:72
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = Intermediate CA for service kubelet TLS
Validity
Not Before: Nov 13 16:08:12 2022 GMT
Not After : Nov 12 16:08:41 2027 GMT
Subject: C = Ukraine, L = Kharkov, street = Lui Pastera st. 322 app. 131, O = K8s The Hardest Way Labs, OU = IT, CN = kubelet.az1.k8s.cluster.home
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Key Identifier:
42:97:B0:18:FC:0A:03:29:02:92:68:A5:F3:5B:A5:48:23:F1:14:DC
X509v3 Authority Key Identifier:
F1:9C:3B:FB:01:4E:9A:3F:F5:E8:28:CE:99:60:9F:E3:5E:51:DA:C8
Authority Information Access:
CA Issuers - URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kubelet_tls/ca
X509v3 Subject Alternative Name:
DNS:kubelet.az1.k8s.cluster.home, DNS:worker01.az1.k8s.cluster.home, IP Address:10.0.12.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://vault.home:8200/v1/k8s_pki_intermediate_ca_for_service_kubelet_tls/crl
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
...
Файлы kubeconfig
Некоторые сервисы используют kubeconfig
для авторизации у kube-apiserver
, в том числе плюс-минус такой же конфиг используется для авторизации администратора
Описание формата kubeconfig
Разберем пример файла (для примера взят конфиг от kubelet
)
apiVersion: v1
clusters:
- cluster:
certificate-authority: "/etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem"
server: https://kube-apiserver.k8s.cluster.home:443
name: kubernetes-the-hardest-way
contexts:
- context:
cluster: kubernetes-the-hardest-way
user: system:node:worker01.az1.k8s.cluster.home
name: default
current-context: default
kind: Config
preferences: {}
users:
- name: system:node:worker01.az1.k8s.cluster.home
user:
client-certificate: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.pem
client-key: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.key
clusters
В этой секции описываются кластера, а именно
- имя кластера
name: kubernetes-the-hardest-way
- Адрес по которому доступен
kube-apiserver
- 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