Vault PKI Intermediate CAs for ALL SERVICES Kubernetes the hard way v2: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
Строка 598: Строка 598:
 
</PRE>
  
</PRE>
 
==Admin==
  
==Admin==
  +
<PRE>
  +
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
  +
</PRE>
  +
 
==Kube-controller-manager==
  
==Kube-controller-manager==
 
<PRE>
  
<PRE>

Версия 17:50, 18 ноября 2022


Эта страница - часть большой статьи про CA используемые в k8s: Vault_PKI_Kubernetes_the_hard_way_v2


Прежде чем начать читать

Эта часть описывает какие именно сертификаты и СА для чего используются разными сервисами - ее можно прочитать перед тем как настаивать Vault для понимания того что и зачем настраивается или после.
Описание настойки Vault для выпуска сертификатов

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

  • CA: certificate authority или certification authority ( на русском это звучит как Центр Сертефикации)

В контексте документа может иметь несколько возможных значений - как собственно центр выпуска сертификатов, так и сам корневой (или промежуточный сертификат) этого центра. По сути, сертификат СА, который используется для подписания клиентских и серверных сертификатом не только не является секретным, но наоборот должен быть доступен для доступа так как именно он используется для проверки валидности выпущенных сертификатов

В случае с PKI на основе Vault СA доступны для скачивания без авторизации.



Есть 2 типа сертификатов (конечно их больше но в K8s используется 2 типа). Потому в целом (кроме etcd) есть разделение СА в том числе и по типу выпускаемых сертификатов

  • client_auth - этот суффикс у СА используется в значении "сертификаты используются для авторизации" (другими словами - не используются для организации http)
  • tls - этот суффикс у СА используется в значении "сертификаты используются для организации https/TLS"

Создание СА для работы кластера 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 сертификаты указываются в файле, определенном в параметре --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

Файлы kubeconfig

Некоторые сервисы используют kubeconfig для авторизации у kube-apiserver, в том числе плюс-минус такой же конфиг используется для авторизации администратора

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

Разберем пример файла (для примера взят конфиг от kubelet) 

apiVersion: v1
clusters:
- cluster:
    certificate-authority: "/etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem"
    server: https://kube-apiserver.k8s.cluster.home:443
  name: kubernetes-the-hardest-way
contexts:
- context:
    cluster: kubernetes-the-hardest-way
    user: system:node:worker01.az1.k8s.cluster.home
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: system:node:worker01.az1.k8s.cluster.home
  user:
    client-certificate: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.pem
    client-key: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.key

clusters

В этой секции описываются кластера, а именно

  • имя кластера

name: kubernetes-the-hardest-way

  • Адрес по которому доступен kube-apiserver

server: https://kube-apiserver.k8s.cluster.home:443

  • CA файл, с помощью которого можно проверить что подключение происходит к правильному кластеру

certificate-authority: /etc/k8s/shared/certs/CA/k8s_pki_intermediate_ca_for_service_kube_apiserver_tls.pem

Имя кластера можно выбрать произвольно, это имя служит только для связывания различных секций файла в единый контекст

users

В этой секции содержится описание пользователя, а именно:

  • Имя пользователя

- name: system:node:worker01.az1.k8s.cluster.home

  • Способ авторизации и параметры авторизации (в этом случае используются клиентские сертификаты
    • client-certificate: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.pem
    • client-key: /etc/k8s/kubelet/certs/client_auth/kube-apiserver-client_auth.key


Имя пользователя в этой секции - просто идентификатор и никак не участвует в процессе авторизации, а служит только для связывания различных секций файла в единый контекст


Важно: Фактические имя пользователя и группа описаны в полях CN (имя пользователя) и O (группа) при авторизации с помощью клиентских сертификатов !!!

Имя в сертификате может не совпадать с полем name, иногда они совпадают для удобства конфигурирования но не более того.

contexts

Эта секция служит для связывания секций users и clusters и по сути просто сообщает для какого кластера какой пользователь используется.
Имя контекста name служит для идентификации, так как в одном файле может быть описано множество контекстов (с возможностью переключения между ними)
Пример файла следует читать так:
Для контекста с именем default использовать СА и адрес определенные в секции clusters в секции где имя кластера kubernetes-the-hardest-way,
для авторизации использовать данные из секции users где имя name - system:node:worker01.az1.k8s.cluster.home
При этом слово default в имени контекста не несет какого-то магического смысла - это просто название, на которое можно сослаться, и не более того. 

contexts:
- context:
    cluster: kubernetes-the-hardest-way
    user: system:node:worker01.az1.k8s.cluster.home
  name: default

current-contex

Эта секция определяет какой контекст будет использоваться по-умолчанию
В примере ниже используется по умолчанию контекст с именем default, и здесь слово default не имеет никакого магического значение - это просто имя контекста определенного в секции contexts и не более того 

current-context: default

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

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
Источник — https://noname.com.ua/mediawiki/index.php?title=Vault_PKI_Intermediate_CAs_for_ALL_SERVICES_Kubernetes_the_hard_way_v2&oldid=10571