Эта страница - часть большой статьи про 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 (который как и прочие СА не является секретным), для того что бы иметь возможность проверить кластер, другими словами быть уверенным в том что подключаются туда куда ожидают.

Часть 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`

Сертификаты K8s `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 Или взять из параметров `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/`	Это СА который используется для проверки сертификатов, с которыми клиенты (другие сервисы или пользователи) подключаются к `kube-apiserver`. Важно, что ключ от этого сертификата в настройках `kube-apiserver` не участвует. Это означает что `kube-apiserver` может проверять сертификаты клиентов но не может выписывать новые сертификаты, эта часть - за администратором системы. В случае 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` используется для того, что бы проверить сертификат `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/`	Это сертификат используется `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`
Сервис который использует этот сертификат	Параметр сервиса	СА выпустивший сертификат	Назначение	Subject и подробности
`kube-controller-manager`	`--tls-cert-file` `--tls-private-key-file`	`kube_controller_manager_tls/`	`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
`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`

Сертификаты K8s `kube-scheduler`
Сервис который использует этот сертификат	Параметр сервиса	СА выпустивший сертификат	Назначение	Subject и подробности
`kube-scheduler`	`--tls-cert-file` `--tls-private-key-file`	СА выпустивший сертификат	`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

`kubelet`

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

Файлы `kubeconfig`

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

| || Текст ячейки ||СА выпустивший сертификат ||Назначение ||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

https://kubernetes.io/docs/setup/best-practices/certificates/

СА для 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

СA для клиентов `kube-apiserver`

Vault PKI Intermediate CAs for ALL SERVICES Kubernetes the hard way v2

Содержание

Некоторые термины

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

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

`k8s_pki_intermediate_ca_for_service_etcd/`

`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_controller_manager_tls/`

`k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/`

`k8s_pki_intermediate_ca_for_service_kubelet_client_auth/` `k8s_pki_intermediate_ca_for_service_kubelet_tls/`

`k8s_pki_root_ca/`

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

`kube-apiserver`

`kube-controller-manager`

`kube-proxy`

`kube-scheduler`

`kubelet`

Файлы `kubeconfig`

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

TLS CA

`kube-apiserver` TLS CA

`kube-controller-manager` TLS CA

`kube-scheduler`TLS CA

`kubelet` TLS CA

Client CA

СА для TLS

Настройка СА

Права, пользователи, роли

Пример получения сертефикатов

СA для клиентов `kube-apiserver`

Навигация

Действия на странице

Действия на странице

Персональные инструменты

Навигация

Поиск

Инструменты

Vault PKI Intermediate CAs for ALL SERVICES Kubernetes the hard way v2

Некоторые термины

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

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

k8s_pki_intermediate_ca_for_service_etcd/

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_controller_manager_tls/

k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/

k8s_pki_intermediate_ca_for_service_kubelet_client_auth/ k8s_pki_intermediate_ca_for_service_kubelet_tls/

k8s_pki_root_ca/

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

kube-apiserver

kube-controller-manager

kube-proxy

kube-scheduler

kubelet

Файлы kubeconfig

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

TLS CA

kube-apiserver TLS CA

kube-controller-manager TLS CA

kube-schedulerTLS CA

kubelet TLS CA

Client CA

СА для TLS

Настройка СА

Права, пользователи, роли

Пример получения сертефикатов

СA для клиентов kube-apiserver

Навигация

Поиск

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

`k8s_pki_intermediate_ca_for_service_etcd/`

`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_controller_manager_tls/`

`k8s_pki_intermediate_ca_for_service_kube_scheduler_tls/`

`k8s_pki_intermediate_ca_for_service_kubelet_client_auth/` `k8s_pki_intermediate_ca_for_service_kubelet_tls/`

`k8s_pki_root_ca/`

`kube-apiserver`

`kube-controller-manager`

`kube-proxy`

`kube-scheduler`

`kubelet`

Файлы `kubeconfig`

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

`kube-apiserver` TLS CA

`kube-controller-manager` TLS CA

`kube-scheduler`TLS CA

`kubelet` TLS CA

СA для клиентов `kube-apiserver`