Vault PKI Intermediate CAs for ALL SERVICES Kubernetes the hard way v2: различия между версиями
Sirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) |
||
Строка 474: | Строка 474: | ||
|| |
|| |
||
<code>kube-scheduler</code> имеет свой API (по умолчанию - на порту 10259), в котором есть как минимум такие endpoints: /healthz, /readyz, /livez, /metrics. |
<code>kube-scheduler</code> имеет свой API (по умолчанию - на порту 10259), в котором есть как минимум такие endpoints: /healthz, /readyz, /livez, /metrics. |
||
− | Этот сертификат служит для организации <code>TLS/HTTPS</code> для этого API<br> |
+ | Этот сертификат служит для организации <code>TLS/HTTPS</code> для этого API<br><br> |
Для разрешения доступа без авторизации служит параметр <code>--authorization-always-allow-paths=/healthz,/readyz,/livez,/metrics<code>, где перечислаются endpoints к которым можно получить доступ. |
Для разрешения доступа без авторизации служит параметр <code>--authorization-always-allow-paths=/healthz,/readyz,/livez,/metrics<code>, где перечислаются endpoints к которым можно получить доступ. |
||
|| |
|| |
Версия 16:35, 18 ноября 2022
Эта страница - часть большой статьи про CA используемые в k8s: Vault_PKI_Kubernetes_the_hard_way_v2
Некоторые термины
CA
: certificate authority или certification authority ( на русском это звучит как Центр Сертефикации)
В контексте документа может иметь несколько возможных значений - как собственно центр выпуска сертификатов, так и сам корневой (или промежуточный сертификат) этого центра. По сути, сертификат СА, который используется для подписания клиентских и серверных сертификатом не только не является секретным, но наоборот должен быть доступен для доступа так как именно он используется для проверки валидности выпущенных сертификатов
В случае с PKI на основе Vault
СA доступны для скачивания без авторизации.
Есть 2 типа сертификатов (конечно их больше но в K8s используется 2 типа). Потому в целом (кроме etcd
) есть разделение СА в том числе и по типу выпускаемых сертификатов
client_auth
- этот суффикс у СА используется в значении "сертификаты используются для авторизации" (другими словами - не используются для организацииhttp
)tls
- этот суффикс у СА используется в значении "сертификаты используются для организацииhttps/TLS
"
Создание СА для работы кластера K8s
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, например kube-controller-manager, kube-scheduler так и kubectl для администрирования) должны обладать CA (который как и прочие СА не является секретным), для того что бы иметь возможность проверить кластер, другими словами быть уверенным в том что подключаются туда куда ожидают.
Часть kubeconfig
отвечающая за этот сертификат:
clusters: - cluster: certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem server: https://kube-apiserver.k8s.cluster.home:443
- Со своей стороны сервер проверяет как то что сертефикат клиента подписан правильным СА (
k8s_pki_intermediate_ca_for_service_kube_apiserver_client_auth/
), так и поляCN
O
в сертификате, которые используются как имя пользователя и группа. Имена групп выбраны не случайно - для них уже есть (или можно создать свои!)ClusterRoleBindings
- Со своей стороны сервер проверяет как то что сертефикат клиента подписан правильным СА (
k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/
k8s_pki_intermediate_ca_for_service_kube_controller_manager_tls/
- используется для обеспечения https, серверные сетефикаты
k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/
k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/
- используется для обеспечения https, серверные сетефикаты
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-api серверу, и использует 2 СА - один для авторизации клиентов (в случае с kubelet клиентом выступает kube-apiserver), а второй используется для обеспечения https- У
kube-apiserver
есть настройка--kubelet-certificate-authority
- это файлс СА для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
Сервис который использует этот сертификат | Параметр сервиса | СА выпустивший сертификат | Назначение | Subject и подробности |
---|---|---|---|---|
kube-apiserver
|
--etcd-certfile --etcd-keyfile
|
etcd
|
Авторизация в 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/
|
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/
|
Это СА который используется для проверки сертификатов, с которыми клиенты (другие сервисы или пользователи) подключаются к 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 используется для того, что бы проверить сертификат 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/
|
Это сертификат используется 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
Сервис который использует этот сертификат | Параметр сервиса | СА выпустивший сертификат | Назначение | Subject и подробности |
---|---|---|---|---|
kube-controller-manager
|
|
kube_controller_manager_tls/
|
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 |
kube-controller-manager
|
--root-ca-file | Root СА | Этот СА которым подписаны сертификаты для 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
Сервис который использует этот сертификат | Параметр сервиса | СА выпустивший сертификат | Назначение | Subject и подробности |
---|---|---|---|---|
kube-scheduler
|
--tls-cert-file --tls-private-key-file
|
СА выпустивший сертификат |
|
Сертификат можно просмотреть: openssl s_client -connect kube-controller-manager.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 |
kubelet
Сервис который использует этот сертификат | Параметр сервиса | СА выпустивший сертификат | Назначение | Subject и подробности |
---|---|---|---|---|
kubelet
|
Текст ячейки | СА выпустивший сертификат | Назначение | Subject и подлробности |
|
|| Текст ячейки
||СА выпустивший сертификат
||Назначение
||Subject и подлробности
|-
|
|| Текст ячейки
||СА выпустивший сертификат
||Назначение
||Subject и подлробности
|}
| 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
||СА выпустивший сертификат ||Назначение ||Subject и подлробности |-
TLS CA
Для того что бы предоставлять API по https нужны следующие СА
kube-apiserver
TLS CA
Для обеспечения https
доступа к API используются 2 параметра - файл сертефиката и файл ключа
--tls-cert-file
--tls-private-key-file
Этот сертификат выпускается k8s_pki_intermediate_ca_for_service_kube_apiserver_tls/
netstat -ntpl| grep kube-api tcp 0 0 10.0.12.1:6443 0.0.0.0:* LISTEN 85224/kube-apiserve
openssl s_client -connect 10.0.12.1:6443 ... 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
kube-controller-manager
TLS CA
--tls-cert-file
--tls-private-key-file
kube-scheduler
TLS CA
--tls-cert-file --tls-private-key-file
kubelet
TLS CA
tlsCertFile
tlsPrivateKeyFile
This parameter should be set via the config file specified by the Kubelet's --config
kind: KubeletConfiguration apiVersion: kubelet.config.k8s.io/v1beta1 ... tlsCertFile: "/etc/k8s/kubelet/tls/kubelet.az1.k8s.home.pem" tlsPrivateKeyFile: "/etc/k8s/kubelet/tls/kubelet.az1.k8s.home.key" authorizationMode: Node,RBAC
Client CA
СА для TLS
Отдельный СА (промежуточный СА!)
Переменные вынесены в отдельный файл
env
export VAULT_ADDR=http://127.0.0.1:8200 export VAULT_TOKEN="s.Yb1J2VamFyYoav3VVE2YQQ88" export PKI_PATH="k8s_pki_intermediate_ca_for_service_kube_apiserver_tls" export N='kube-apiserver'
Настройка СА
#!/bin/bash source ../env vault \ secrets \ enable \ -path=${PKI_PATH} \ -description="PKI Intermediate CA for K8S kube-apiserver API endpoints" \ -max-lease-ttl="175200h" \ pki
#!/bin/bash source ../env 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
#!/bin/bash source ../env vault \ write \ -format=json \ k8s_pki_root_ca/root/sign-intermediate \ csr=@${PKI_PATH}_intermediate_ca.csr \ country="Ukraine" \ locality="Kharkov" \ street_address="Lui Pastera st. 322 app. 131" \ postal_code="61172" \ organization="K8s The Hardest Way Labs" \ ou="IT" \ format=pem_bundle \ ttl="175200h" > ${PKI_PATH}_intermediate_ca_pem_bundle.json 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
#!/bin/bash source ../env openssl \ verify \ -verbose \ -CAfile k8s_root_certificate.pem \ ${PKI_PATH}_intermediate_ca_pem.crt
#!/bin/bash source ../env vault \ write \ ${PKI_PATH}/intermediate/set-signed \ certificate=@${PKI_PATH}_intermediate_ca_pem.crt \ key=@${PKI_PATH}_intermediate_ca.key
Права, пользователи, роли
Далее назначить права на пользователей для каждого экземпляра сервера
#!/bin/bash source ../env N='kube-apiserver' for AZ in $(seq 1 3); do DOMAIN="${N}.az${AZ}.k8s.cluster.home" BALANCER_DOMAIN="${N}.k8s.cluster.home" NAME_SERVER="${DOMAIN}-server" NAME_CLIENT="${DOMAIN}-client" vault \ write \ ${PKI_PATH}/roles/${NAME_SERVER}-role \ country="Ukraine" \ locality="Kharkov" \ street_address="Lui Pastera st 322 app. 311"\ postal_code="61172" \ organization="Home Network" \ ou="IT" \ allowed_domains="${DOMAIN},${BALANCER_DOMAIN}" \ allow_subdomains=false \ max_ttl="87600h" \ key_bits="2048" \ key_type="rsa" \ allow_any_name=false \ allow_bare_domains=true \ allow_glob_domain=false \ allow_ip_sans=true \ allow_localhost=false \ client_flag=true \ server_flag=true \ enforce_hostnames=true \ key_usage="DigitalSignature,KeyEncipherment" \ ext_key_usage="ServerAuth" \ require_cn=true vault \ write \ ${PKI_PATH}/roles/${NAME_CLIENT}-role \ country="Ukraine" \ locality="Kharkov" \ street_address="Lui Pastera st 322 app. 311"\ postal_code="61172" \ organization="Home Network" \ ou="IT" \ 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
#!/bin/bash source ../env N='kube-apiserver' for AZ in $(seq 1 3); do 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 vault \ policy \ write \ ${NAME_CLIENT}-policy \ ${NAME_CLIENT}-policy.hlc vault \ write \ auth/userpass/users/${NAME_CLIENT}-user \ password=${NAME_CLIENT}-password \ policies=" ${NAME_CLIENT}-policy,default" done
#!/bin/bash source ../env echo "---------ROLES---------------------" vault \ list \ ${PKI_PATH}/roles echo "---------USERS---------------------" vault \ list \ auth/userpass/users echo "------------------------------" for AZ in $(seq 1 3); do echo "------ AZ ${AZ} -----" DOMAIN="${N}.az${AZ}.k8s.cluster.home" NAME_SERVER="${DOMAIN}-server" NAME_CLIENT="${DOMAIN}-client" vault \ policy \ 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
Пример получения сертефикатов
на конечных нодах используя имя пользователя и пароль а так же переменную AZ определнную на нодах индивидуально (Сертефикаты для kube-apiserver
--tls-cert-file
и --tls-private-key-file
)
#!/bin/bash set -eu${DEBUG:+x} 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" DATE=$(date +%Y%m%dT%H%M) USERNAME="${N}-${AZ}-tls" echo "========" vault \ write \ -format=json \ ${PKI_NAME}/issue/${NAME_SERVER}-role \ common_name="${DOMAIN}" \ alt_names="${DOMAIN},${BALANCER_DOMAIN}" \ ip_sans="${IP}" \ ca=false \ ttl="43800h" \ > ${CERTS_PATH}/${USERNAME}.crt.json cat \ ${CERTS_PATH}/${USERNAME}.crt.json \ | jq -r '.data.private_key' > ${CERTS_PATH}/${USERNAME}-${DATE}.key cat \ ${CERTS_PATH}/${USERNAME}.crt.json \ | 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