Cert

Задача - Корневой сертификат удостоверяющего центра AD-CA на Linux

Условие1. поднять PKI-AD, при этом корневой центр сертификации должен быть установлен на отдельной станции ROOT-CA.
Условие2. так как станция ROOT-CA используется крайне ограниченные время и только на выпуск CRT и CRL, то на 99% станция находится отключенном состоянии, бюджет на данную станцию равен нулю.

Размышления

Размышления крайне просты: для экономии бюджета PKI-AD будет установлена непосредственно на сервер Active Decretory, а вот ROOT-CA требуется поднять на Linux.

Далее по тексту:

• ROOT-CA станция либо сертификат корневого центра.

• PKI AD-CA станция с ролью Службы сертификатов Active Decretory

Решение

Подготовка ROOT-CA. (CentOS7)

Корневой сертификат ROOT-CA, будем выпускать на CentOS, там-же будем подписывать сертификат для PKI AD-CA.

Для решения данной задачи на машине с Linux необходимо установить пакет easy-rsa, который содержится в репетиторе epel-release

yum install epel-releas

yum install easy-rsa

Более подробно с документацией к easy-rsa можно ознакомится на GitHub/OpenVPN

После того как мы установили easy-rsa мы можем создать главный удостоверяющий центр сертификации.

(Все операции буду выполнять из под пользователя root)

Создадим в директории пользователя, каталог - в котором будем хранить наш PKI

mkdir -p ~/ROOTca

Далее нужно скопировать последнюю версию easy-rsa в наш каталог ROOTca,

dir /usr/share/easy-rsa/

В моём случаи последняя версия 3.0.8. Её и будем копировать.

Копируем easy-rsa в каталог ROOTca

cp -R /usr/share/easy-rsa/3.0.8/* ~/ROOTca

теперь нам необходимо создать файл ответов vars, и отредактировать его

создаем и сразу редактируем

cat > ~/ROOTca/vars

пример файла vars с описанием

собираем файл vars, у меня получилось так:

# A little housekeeping: DON'T EDIT THIS SECTION  (ну нет так нет)# Easy-RSA 3.x doesn't source into the environment directly.if [ -z "$EASYRSA_CALLER" ]; thenecho "You appear to be sourcing an Easy-RSA 'vars' file." >&2echo "This is no longer necessary and is disallowed. See the section called" >&2echo "'How to use this file' near the top comments for more details." >&2return 1fi# пути set_var EASYRSA "$PWD"set_var EASYRSA_PKI "$EASYRSA/pki"set_var EASYRSA_OPENSSL"openssl"set_var EASYRSA_DN  "org"set_var EASYRSA_TEMP_FILE "$EASYRSA_PKI/extensions.temp"set_var EASYRSA_EXT_DIR "$EASYRSA/x509-types"set_var EASYRSA_SSL_CONF "$EASYRSA/openssl-easyrsa.cnf"set_var EASYRSA_BATCH ""# Заполняем данные организацииset_var EASYRSA_REQ_COUNTRY "RU"set_var EASYRSA_REQ_PROVINCE "Russia"set_var EASYRSA_REQ_CITY "Moscow"set_var EASYRSA_REQ_ORG "CompanyName"set_var EASYRSA_REQ_EMAIL "ca@companyname.ru"set_var EASYRSA_REQ_OU "CompanyName.ru" set_var EASYRSA_NS_SUPPORT "yes"set_var EASYRSA_NS_COMMENT "CompanyName Certificate 2021"# размер ключа сертификата и алгоритмset_var EASYRSA_KEY_SIZE 4096set_var EASYRSA_ALGO rsa# срок действия корневого сертификата в днях  (20 лет) set_var EASYRSA_CA_EXPIRE 7300# Срок действия выпускаемых сертификатовset_var EASYRSA_CERT_EXPIRE 365# Время действия списка отзыва ~ кварталset_var EASYRSA_CRL_DAYS 92# выпускаемый сертификатset_var EASYRSA_DIGEST "sha256"

Теперь все готово, можно начинать!

Внимание! Вовремя всех действий, вы должны находится в директории ROOTca

cd ~/ROOTca

Инициализируем наш центр сертификации

./easyrsa init-pki

Отлично, мы готовы выпустить наш ROOT-CA

Выпускаем

./easyrsa build-ca

Система попросит придумать пароль для секретного ключа нашего ROOT-CA

(для наших задач, пароль должен быть не менее 4 символов)

Проверяем параметры выпускаемого сертификата, они берутся из vars, соглашаемся либо меняем на нужные.

!!! В какой-то момент система спросит название Common Name. Это название будет основным названиям нашего сертификата

Common Name (eg: your user, host, or server name) [Easy-RSA CA]: Указываем CompanyName Certificate 2021.

По окончанию мы получим корневой сертификат ROOT-ca нашего PKI

Он располагается пути /root/ROOTca/pki/ca.crt

Копируем корневой сертификат на станцию c PKI AD-CA

Сервер с PKI AD-CA (Windows Server)

Проверяем полученный файл на станции PKI AD-CA

Открываем ca.crt и проверяем содержимое

ca.crt

Все отлично! Переименуем ca.crt в ROOT-ca.crt, так как-то удобнее. Теперь нужно подготовить службу Центра сертификации Windows.

Устанавливаем роль Службы сертификатов Active Decretory

в моем случае, я устанавливаю Службы сертификатов Active Decretory на отдельный ПК, все действия для PKI AD-CA идентичны

После установки переходим к настройке - Службы сертификатов Active Decretory

Более детально с настройкой и установкой можно ознакомится на docs.microsoft.com

в момент настройки выбираем следующие опции:

• ЦС - предприятия

  

• Наш сервер будет- подчиненным ЦС

  

• Нам нужно создать новый закрытый ключ

  

• Шифрование - выбираем по вкусу

  

• Указываем имя CA

  

• Запрос сертификата - указываем через REQ файл

  

  По окончанию настройки мы получаем следующее сообщение:

  

Хорошо, теперь у нас есть файл pki-ca_PKI-CA-CA.req

Копируем полученный файл на машину с Linux ROOT-ca в директорию /root/ROOTca/pki/

Все готово к выпуску сертификата для PKI AD-CA

Перед тем как выпустить сертификат нужно импортировать req файл в PKI

импортируем

./easyrsa import-req /root/ROOTca/pki/pki-ca_PKI-CA-CA.req CompanyName-AD

Где CompanyName-AD название центра PKI AD-CA

Проверяем что получилось

./easyrsa show-req CompanyName-AD

Пора выпустить сертификат для CompanyName-AD

./easyrsa sign-req ca CompanyName-AD

Так как мы выпускаем сертификат для Центра сертификации указываем именно ca, если нужно выпустить на отдельный сервер указываем server.

мы получили наш сертификат для PKI AD-CA по пути /root/ROOTca/pki/issued/CompanyName-AD.crt

Копируем его на станцию с PKI AD-CA

Также нам нужны списки отзыва CRL, с генерируем и их

Получили /root/ROOTca/pki/crl.pem

(Напоминаю что действия наших списков 92 дня см файл vars,в течении 92 дней нужно повторить операцию передачи CRL)

Копируем crl.pem также на станцию с AD-PKI

Сервер с PKI AD-CA (Windows Server)

Сейчас у нас есть все, что нам нужно.

А именно:

• Корневой сертификат: ROOT-ca.crt

• Сертификат CA для нашего сервера: CompanyName-AD.crt

• Списки отзыва: crl.pem

Импорт ROOT-ca

Нам нужно сделать ROOT-ca.crt стал валидным сертификатом в системе Windows, напоминаю, что сейчас он с крестом и нас, конечно, такой вариант не устраивает.

Запускам MMC-консоль и подключаем оснастку Сертификаты для учетной записи компьютера.

Переходим по пути: Сертификаты\Доверительные корневые центры\Сертификаты

Добавим наш сертификат ROOT-ca.crt в "Доверительные корневые центры"

Для этого правой кнопкой по папке сертифкаты -> импорт

Указываем путь к сертификату ROOT-ca.crt и импортируем его.

После импорта сертификат должен появиться в списке

Теперь, проверяем сам файл ROOT-ca.crt

Так-то куда лучше!

(Данный сертификат нужно также распространить через групповые политики, на все ПК в AD)

Импорт CRL.

Нам также нужно импортировать списки отзыва, для этого необходимо переименовать файл crl.pem в ROOTca.crl

(теперь можно изучить файл ROOTca.crl)

Импортируем его точно также как и сертификат в доверительные корневые центры ROOT-ca.crt

Активация PKI AD-CA

Теперь можно приступить к активации нашего CA PKI AD-CA

Запускаем средство "Центр сертификации"

Перед установкой сертификата в CA, лучше предварительно настроить публикацию CDP и AIA

Активируем CA

Правой кнопкой мыши по серверу PKI AD-CA > Все задачи > Установить сертификат ЦС

Далее, указываем файл CompanyName-AD.crt и подтверждаем.

Если мы все сделали правильно, установка сертификата в CA должна пройти без ошибок и предупреждений.

Если вы не можете импортировать CompanyName-AD.crt система просит P7B файл.

Необходимо выполнить слияние CompanyName-AD.crt с ROOT-ca.crt в OpenSSL следующей командой:

openssl crl2pkcs7 -nocrl certfile ROOT-ca.crt -certfile CompanyName-AD.crt -out CompanyName-AD.p7b

Запуск PKI AD-CA

теперь мы можем запустить службу Центра сертификации

Правой кнопкой мыши по серверу PKI AD-CA > Все задачи > Запуск службы

Итог

мы получили рабочий PKI - Active Decretory и можем начать выпуск сертификатов для пользователей, станций, серверов. При этом ROOT-ca находится на станции с Linux, и нам не пришлось отдавать под данную задачу отдельный сервер с Windows.

Задача - Корневой сертификат удостоверяющего центра AD-CA на Linux

Условие1. поднять PKI-AD, при этом корневой центр сертификации должен быть установлен на отдельной станции ROOT-CA.
Условие2. так как станция ROOT-CA используется крайне ограниченные время и только на выпуск CRT и CRL, то на 99% станция находится отключенном состоянии, бюджет на данную станцию равен нулю.

Размышления

Размышления крайне просты: для экономии бюджета PKI-AD будет установлена непосредственно на сервер Active Directory, а вот ROOT-CA требуется поднять на Linux.

Далее по тексту:

• ROOT-CA станция либо сертификат корневого центра.

• PKI AD-CA станция с ролью Службы сертификатов Active Directory

Решение

Подготовка ROOT-CA. (CentOS7)

Корневой сертификат ROOT-CA, будем выпускать на CentOS, там-же будем подписывать сертификат для PKI AD-CA.

Для решения данной задачи на машине с Linux необходимо установить пакет easy-rsa, который содержится в репетиторе epel-release

yum install epel-releas

yum install easy-rsa

Более подробно с документацией к easy-rsa можно ознакомится на GitHub/OpenVPN

После того как мы установили easy-rsa мы можем создать главный удостоверяющий центр сертификации.

(Все операции буду выполнять из под пользователя root)

Создадим в директории пользователя, каталог - в котором будем хранить наш PKI

mkdir -p ~/ROOTca

Далее нужно скопировать последнюю версию easy-rsa в наш каталог ROOTca,

dir /usr/share/easy-rsa/

В моём случаи последняя версия 3.0.8. Её и будем копировать.

Копируем easy-rsa в каталог ROOTca

cp -R /usr/share/easy-rsa/3.0.8/* ~/ROOTca

теперь нам необходимо создать файл ответов vars, и отредактировать его

создаем и сразу редактируем

cat > ~/ROOTca/vars

пример файла vars с описанием

собираем файл vars, у меня получилось так:

# A little housekeeping: DON'T EDIT THIS SECTION  (ну нет так нет)# Easy-RSA 3.x doesn't source into the environment directly.if [ -z "$EASYRSA_CALLER" ]; thenecho "You appear to be sourcing an Easy-RSA 'vars' file." >&2echo "This is no longer necessary and is disallowed. See the section called" >&2echo "'How to use this file' near the top comments for more details." >&2return 1fi# пути set_var EASYRSA "$PWD"set_var EASYRSA_PKI "$EASYRSA/pki"set_var EASYRSA_OPENSSL"openssl"set_var EASYRSA_DN  "org"set_var EASYRSA_TEMP_FILE "$EASYRSA_PKI/extensions.temp"set_var EASYRSA_EXT_DIR "$EASYRSA/x509-types"set_var EASYRSA_SSL_CONF "$EASYRSA/openssl-easyrsa.cnf"set_var EASYRSA_BATCH ""# Заполняем данные организацииset_var EASYRSA_REQ_COUNTRY "RU"set_var EASYRSA_REQ_PROVINCE "Russia"set_var EASYRSA_REQ_CITY "Moscow"set_var EASYRSA_REQ_ORG "CompanyName"set_var EASYRSA_REQ_EMAIL "ca@companyname.ru"set_var EASYRSA_REQ_OU "CompanyName.ru" set_var EASYRSA_NS_SUPPORT "yes"set_var EASYRSA_NS_COMMENT "CompanyName Certificate 2021"# размер ключа сертификата и алгоритмset_var EASYRSA_KEY_SIZE 4096set_var EASYRSA_ALGO rsa# срок действия корневого сертификата в днях  (20 лет) set_var EASYRSA_CA_EXPIRE 7300# Срок действия выпускаемых сертификатовset_var EASYRSA_CERT_EXPIRE 365# Время действия списка отзыва ~ кварталset_var EASYRSA_CRL_DAYS 92# выпускаемый сертификатset_var EASYRSA_DIGEST "sha256"

Теперь все готово, можно начинать!

Внимание! Вовремя всех действий, вы должны находится в директории ROOTca

cd ~/ROOTca

Инициализируем наш центр сертификации

./easyrsa init-pki

Отлично, мы готовы выпустить наш ROOT-CA

Выпускаем

./easyrsa build-ca

Система попросит придумать пароль для секретного ключа нашего ROOT-CA

(для наших задач, пароль должен быть не менее 4 символов)

Проверяем параметры выпускаемого сертификата, они берутся из vars, соглашаемся либо меняем на нужные.

!!! В какой-то момент система спросит название Common Name. Это название будет основным названиям нашего сертификата

Common Name (eg: your user, host, or server name) [Easy-RSA CA]: Указываем CompanyName Certificate 2021.

По окончанию мы получим корневой сертификат ROOT-ca нашего PKI

Он располагается пути /root/ROOTca/pki/ca.crt

Копируем корневой сертификат на станцию c PKI AD-CA

Сервер с PKI AD-CA (Windows Server)

Проверяем полученный файл на станции PKI AD-CA

Открываем ca.crt и проверяем содержимое

ca.crt

Все отлично! Переименуем ca.crt в ROOT-ca.crt, так как-то удобнее. Теперь нужно подготовить службу Центра сертификации Windows.

Устанавливаем роль Службы сертификатов Active Directory

в моем случае, устанавливаю Службы сертификатов Active Directory на отдельный ПК, все действия для PKI AD-CA идентичны

После установки переходим к настройке - Службы сертификатов Active Directory

Более детально с настройкой и установкой можно ознакомится на docs.microsoft.com

в момент настройки выбираем следующие опции:

• ЦС - предприятия

  

• Наш сервер будет- подчиненным ЦС

  

• Нам нужно создать новый закрытый ключ

  

• Шифрование - выбираем по вкусу

  

• Указываем имя CA

  

• Запрос сертификата - указываем через REQ файл

  

  По окончанию настройки мы получаем следующее сообщение:

  

Хорошо, теперь у нас есть файл pki-ca_PKI-CA-CA.req

Копируем полученный файл на машину с Linux ROOT-ca в директорию /root/ROOTca/pki/

Все готово к выпуску сертификата для PKI AD-CA

Перед тем как выпустить сертификат нужно импортировать req файл в PKI

импортируем

./easyrsa import-req /root/ROOTca/pki/pki-ca_PKI-CA-CA.req CompanyName-AD

Где CompanyName-AD название центра PKI AD-CA

Проверяем что получилось

./easyrsa show-req CompanyName-AD

Пора выпустить сертификат для CompanyName-AD

./easyrsa sign-req ca CompanyName-AD

Так как мы выпускаем сертификат для Центра сертификации указываем именно ca, если нужно выпустить на отдельный сервер указываем server.

мы получили наш сертификат для PKI AD-CA по пути /root/ROOTca/pki/issued/CompanyName-AD.crt

Копируем его на станцию с PKI AD-CA

Также нам нужны списки отзыва CRL, с генерируем и их

Получили /root/ROOTca/pki/crl.pem

(Напоминаю что действия наших списков 92 дня см файл vars,в течении 92 дней нужно повторить операцию передачи CRL)

Копируем crl.pem также на станцию с AD-PKI

Сервер с PKI AD-CA (Windows Server)

Сейчас у нас есть все, что нам нужно.

А именно:

• Корневой сертификат: ROOT-ca.crt

• Сертификат CA для нашего сервера: CompanyName-AD.crt

• Списки отзыва: crl.pem

Импорт ROOT-ca

Нам нужно сделать ROOT-ca.crt стал валидным сертификатом в системе Windows, напоминаю, что сейчас он с крестом и нас, конечно, такой вариант не устраивает.

Запускам MMC-консоль и подключаем оснастку Сертификаты для учетной записи компьютера.

Переходим по пути: Сертификаты\Доверительные корневые центры\Сертификаты

Добавим наш сертификат ROOT-ca.crt в "Доверительные корневые центры"

Для этого правой кнопкой по папке сертифкаты -> импорт

Указываем путь к сертификату ROOT-ca.crt и импортируем его.

После импорта сертификат должен появиться в списке

Теперь, проверяем сам файл ROOT-ca.crt

Так-то куда лучше!

(Данный сертификат нужно также распространить через групповые политики, на все ПК в AD)

Импорт CRL.

Нам также нужно импортировать списки отзыва, для этого необходимо переименовать файл crl.pem в ROOTca.crl

(теперь можно изучить файл ROOTca.crl)

Импортируем его точно также как и сертификат в доверительные корневые центры ROOT-ca.crt

Активация PKI AD-CA

Теперь можно приступить к активации нашего CA PKI AD-CA

Запускаем средство "Центр сертификации"

Перед установкой сертификата в CA, лучше предварительно настроить публикацию CDP и AIA

Активируем CA

Правой кнопкой мыши по серверу PKI AD-CA > Все задачи > Установить сертификат ЦС

Далее, указываем файл CompanyName-AD.crt и подтверждаем.

Если мы все сделали правильно, установка сертификата в CA должна пройти без ошибок и предупреждений.

Если вы не можете импортировать CompanyName-AD.crt система просит P7B файл.

Необходимо выполнить слияние CompanyName-AD.crt с ROOT-ca.crt в OpenSSL следующей командой:

openssl crl2pkcs7 -nocrl certfile ROOT-ca.crt -certfile CompanyName-AD.crt -out CompanyName-AD.p7b

Запуск PKI AD-CA

теперь мы можем запустить службу Центра сертификации

Правой кнопкой мыши по серверу PKI AD-CA > Все задачи > Запуск службы

Итог

мы получили рабочий PKI - Active Directory и можем начать выпуск сертификатов для пользователей, станций, серверов. При этом ROOT-ca находится на станции с Linux, и нам не пришлось отдавать под данную задачу отдельный сервер с Windows.

Неделю назад мне подкинули задачу - обновить сертификаты k8s кластере. С одной стороны задача казалась достаточно тривиальной, НО нетривиальности добавляло моя неуверенность с k8s: до этого момента я пользовался кубером как сервисом и больше чем посмотреть на поды, удалить их написать deployment по шаблону делать ничего не доводилось. Уверенности добавляло наличие инструкции, но как выяснилось она для версии v1.13 а у кластера для, которого требовалось реализовать эту задачу версия была 1.12.3. И тут началось

3-го числа задачу с обновлением решил и захотелось написать инструкцию. Слышал, что в новых версиях сейчас эта задача решается чуть ли не одной командой, но для тех у кого оказался такой же винтаж как и у меня делюсь своим опытом.

Дано k8s кластер:

• 3 master ноды

• 3 etcd ноды

• 5 worker нод

kubectl get nodesNAME                    STATUS   ROLES    AGE    VERSIONproduct1-mvp-k8s-0001   Ready    master   464d   v1.12.3product1-mvp-k8s-0002   Ready    master   464d   v1.12.3product1-mvp-k8s-0003   Ready    master   464d   v1.12.3product1-mvp-k8s-0007   Ready    node     464d   v1.12.3product1-mvp-k8s-0008   Ready    node     464d   v1.12.3product1-mvp-k8s-0009   Ready    node     464d   v1.12.3product1-mvp-k8s-0010   Ready    node     464d   v1.12.3product1-mvp-k8s-0011   Ready    node     464d   v1.12.3

Срок действия сертификата

echo | openssl s_client -showcerts -connect product1-mvp-k8s-0001:6443 -servername api 2>/dev/null | openssl x509 -noout -enddatenotAfter=Mar  4 00:39:56 2021 GMT

Поехали:

• на всех MASTER нодах бэкапируем /etc/kubernetes

sudo mkdir backup; sudo cp -R /etc/kubernetes backup/ ; sudo tar -cvzf backup/pki_backup_`hostname`-`date +%Y%m%d`.tar.gz backup/kubernetes/

• Смотрим в структуру /etc/Kubernetes она будет примерно такой

ls -ltotal 80-rw------- 1 root root 5440 Mar  3 13:21 admin.confdrwxr-xr-x 2 root root 4096 Aug 17  2020 audit-policy-rw-r--r-- 1 root root  368 Mar  4  2020 calico-config.yml-rw-r--r-- 1 root root  270 Mar  4  2020 calico-crb.yml-rw-r--r-- 1 root root  341 Mar  4  2020 calico-cr.yml-rw-r--r-- 1 root root  147 Mar  4  2020 calico-node-sa.yml-rw-r--r-- 1 root root 6363 Mar  4  2020 calico-node.yml-rw------- 1 root root 5472 Mar  3 13:21 controller-manager.conf-rw-r--r-- 1 root root 3041 Aug 14  2020 kubeadm-config.v1alpha3.yaml-rw------- 1 root root 5548 Mar  3 13:21 kubelet.conf-rw-r--r-- 1 root root 1751 Mar  4  2020 kubelet.envdrwxr-xr-x 2 kube root 4096 Aug 14  2020 manifestslrwxrwxrwx 1 root root   28 Mar  4  2020 node-kubeconfig.yaml -> /etc/kubernetes/kubelet.conf-rw------- 1 root root 5420 Mar  3 13:21 scheduler.confdrwxr-xr-x 3 kube root 4096 Mar  3 10:20 ssl

у меня все ключи в ssl, а не в pki , который будет нужен kubeadm , то он должен появиться, в своем случае я сделаю на него symlink

ln -s /etc/kubernetes/ssl /etc/kubernetes/pki

• отыскиваем файл с конфигурацией кластера, в моем случае это был

  kubeadm-config.v1alpha3.yaml

если такового вдруг нет то его возможно сгенерировать

kubectl get cm kubeadm-config -n kube-system -o yaml > /etc/kubernetes/kubeadm-config.yaml

• Начинаем перегенерацию сертификатов

kubeadm alpha phase certs apiserver  --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml[certificates] Using the existing apiserver certificate and key.kubeadm alpha phase certs apiserver-kubelet-clientI0303 13:12:24.543254   40613 version.go:236] remote version is much newer: v1.20.4; falling back to: stable-1.12[certificates] Using the existing apiserver-kubelet-client certificate and key.kubeadm alpha phase certs front-proxy-clientI0303 13:12:35.660672   40989 version.go:236] remote version is much newer: v1.20.4; falling back to: stable-1.12[certificates] Using the existing front-proxy-client certificate and key.kubeadm alpha phase certs  etcd-server --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml[certificates] Generated etcd/server certificate and key.[certificates] etcd/server serving cert is signed for DNS names [prod-uct1-mvp-k8s-0001 localhost] and IPs [127.0.0.1 ::1]kubeadm alpha phase certs  etcd-server --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml[certificates] Using the existing etcd/server certificate and key.kubeadm alpha phase certs  etcd-healthcheck-client --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml[certificates] Generated etcd/healthcheck-client certificate and key.kubeadm alpha phase certs  etcd-peer --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml[certificates] Generated etcd/peer certificate and key.[certificates] etcd/peer serving cert is signed for DNS names [product1-mvp-k8s-0001 localhost] and IPs [192.168.4.201 127.0.0.1 ::1]

• проверяем выпущенные сертификаты на актуальность

find /etc/kubernetes/pki/ -name '*.crt' -exec openssl x509 -text -noout -in {} \; | grep -A2 Validity        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  2 10:29:44 2030 GMT--        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  3 10:07:29 2022 GMT--        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  3 10:07:52 2022 GMT--        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  3 10:06:48 2022 GMT--        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  2 10:29:44 2030 GMT--        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  2 19:39:56 2022 GMT--        Validity            Not Before: Mar  4 10:29:43 2020 GMT            Not After : Mar  2 10:29:43 2030 GMT--        Validity            Not Before: Mar  4 10:29:43 2020 GMT            Not After : Mar  2 19:40:13 2022 GMT--        Validity            Not Before: Mar  4 10:29:44 2020 GMT            Not After : Mar  2 19:36:38 2022 GMT

• В процессе обновления сертификатов буду выпущены заново файлы admin.conf, controller-manager.conf, kubelet.conf, scheduler.conf а существующие переносим в подпапку tmpи генерим новые файлы

kubeadm alpha phase kubeconfig all  --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml [kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/admin.conf"[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/kubelet.conf"[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/controller-manager.conf"[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/scheduler.conf"

• перезапускаем все контейнеры и kubelet мастер ноды и проверяем что сервис kubelet завершил перезапуск

sudo systemctl stop kubelet; sudo docker stop $(docker ps -aq); sudo docker rm $(docker ps -aq); sudo systemctl start kubeletsystemctl status kubelet -l kubelet.service - Kubernetes Kubelet Server   Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)   Active: active (running) since Wed 2021-03-03 14:00:22 MSK; 10s ago     Docs: https://github.com/GoogleCloudPlatform/kubernetes  Process: 52998 ExecStartPre=/bin/mkdir -p /var/lib/kubelet/volume-plugins (code=exited, status=0/SUCCESS) Main PID: 53001 (kubelet)   Memory: 51.2M   CGroup: /system.slice/kubelet.service

• проверяем что master нода вернулась нормально в кластер и что доступна конфигурация namespace

kubectl get nodeskubectl get nsNAME STATUS AGEdefault Active 464dproduct1-mvp Active 318dinfra-logging Active 315dinfra-nginx-ingress Active 386dkube-public Active 464dkube-system Active 464dpg Active 318d

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

notAfter=Mar 3 07:40:43 2022 GMT

Обновление сертификатов на master ноде 1 успешно завершено и повторяем туже процедуру на оставшихся 2-х.

---

Далее обновляем worker ноды:

• удаляем или переименовываем kubelet.conf, необходимо для того чтобы при перезапуске подхватился файл bootstrap-kubelet.conf

cd /etc/kubernetes/mv kubelet.conf kubelet.conf_old

• вносим изменения в файл bootstrap-kubelet.conf если его нет, то создаем по шаблону внизу

apiVersion: v1clusters:- cluster: certificate-authority-data: | LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01ETX server: https://192.168.4.201:6443 name: product1contexts:- context: cluster: product1 user: tls-bootstrap-token-user name: tls-bootstrap-token-user@product1current-context: tls-bootstrap-token-user@product1kind: Configpreferences: {}users:- name: tls-bootstrap-token-user user: token: fgz9qz.lujw0bwsdfhdsfjhgds

где мы должны заменить

- certificate-authority-data корневой сертификат центра сертификации PKI CA мастера, берем например из файла /etc/kubernetes/kubelet.conf на master ноде

- server: https://192.168.4.201:6443 - ip api сервера master ноды, или же виртуальный balance ip

token: fgz9qz.lujw0bwsdfhdsfjhgds - токен, который генерим на master ноде

kubeadm token create

• перезапускаем kubelet и проверяем результат с master ноды, work нода должна ,быть доступна ready в ресурсе кластера

systemctl restart kubeletsystemctl status kubelet -l kubelet.service - Kubernetes Kubelet Server Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2021-03-03 14:06:33 MSK; 11s ago Docs: https://github.com/GoogleCloudPlatform/kubernetes Process: 54615 ExecStartPre=/bin/mkdir -p /var/lib/kubelet/volume-plugins (code=exited, status=0/SUCCESS)Main PID: 54621 (kubelet) Memory: 52.1M CGroup: /system.slice/kubelet.service

• проверить, что сертификат обновлен посмотреть на обновление сертификатов в папке

ls -las /var/lib/kubelet/pki/total 244 -rw-------. 1 root root 1135 Mar 3 14:06 kubelet-client-2021-03-03-14-06-34.pem0 lrwxrwxrwx. 1 root root 59 Mar 3 14:06 kubelet-client-current.pem -> /var/lib/kubelet/pki/kubelet-client-2021-03-03-14-06-34.pem4 -rw-r--r--. 1 root root 2267 Mar 2 10:40 kubelet.crt4 -rw-------. 1 root root 1679 Mar 2 10:40 kubelet.key

Повторяем подобную процедуру на всех оставшихся work нодах.

Все мы обновили сертификаты на k8s кластере v1.12.3