Перейти к содержанию

Два режима доставки credential

Как именно kubectl получает то, что предъявит кластеру. Режима два, они равноправны, и выбор — ваш. Что это за функция целиком — в обзоре раздела.

Почему режимов два

kubectl не умеет пользоваться ключом, который нельзя прочитать. Это ограничение самого Kubernetes, а не Alatyr: внешняя подпись в его клиентской библиотеке не поддерживается, а принятая в проекте позиция прямо гласит, что интеграции с аппаратными ключами подписывают короткоживущие credential, а не участвуют в TLS-рукопожатии.

Обойти это можно двумя способами, и Alatyr умеет оба.

Режим 1. Плагин credential

Режим по умолчанию: именно его настраивает пошаговая инструкция.

kubectl сам вызывает агента Alatyr на каждое обращение к кластеру. Агент создаёт эфемерный ключ в памяти, брокер подписывает ему сертификат на десять минут, и плагин отдаёт это kubectl. На диск не попадает ничего — Kubernetes прямо фиксирует, что эти данные идут только между kubectl и плагином.

alatyr-agent k8s kubeconfig                          # один раз
export KUBECONFIG=$HOME/.kube/alatyr.config:$HOME/.kube/config
kubectl get nodes                                    # дальше просто работает

Ничего запускать и держать не нужно: kubectl вызывает плагин сам, а между вызовами не существует ни процесса, ни ключа, ни сертификата.

Режим 2. Локальный прокси

Здесь kubectl вообще не получает клиентского сертификата. Агент поднимает по слушателю на 127.0.0.1 на каждый кластер, пишет kubeconfig, указывающий на них, и сам держит mTLS к API-серверу аппаратным ключом. Работает, пока команду не остановят.

alatyr-agent k8s proxy

Смысл режима один и формулируется узко: приватного ключа не появляется даже в памяти чужого процесса. Есть среды, где эфемерный ключ на десять минут не принимают именно поэтому.

Петлевой порт закрыт двумя замками. Первый — токен, который создаётся на запуск, живёт в памяти и попадает только в kubeconfig Alatyr (права 0600), удаляемый при остановке. Второй — сверка пользователя, от которого пришло подключение; «не смогли определить» означает отказ, а не разрешение.

Локальный прокси НЕ строже, и продавать его так нельзя

Пока прокси запущен, петлевым портом может воспользоваться любой процесс того же пользователя. Это окно длиннее десятиминутного сертификата, а не короче.

Что режим действительно убирает — приватный ключ в памяти чужого процесса. Чего он не убирает — возможность локального процесса просто воспользоваться доступом. Закрывает это только подтверждение человеком, и в этом режиме вопрос задаётся один раз на сессию, а не на каждый запрос: kubectl делает их десятки, и вопрос на каждый научил бы нажимать «да» не глядя.

Чем они отличаются

Плагин credential Локальный прокси
Что нужно запускать ничего, kubectl вызывает плагин сам alatyr-agent k8s proxy, и держать запущенным
Где живёт ключ, которым идёт mTLS к кластеру эфемерный, в памяти kubectl и плагина в чипе, наружу не выходит вовсе
Что видит кластер сертификат на 10 минут тот же самый сертификат
Окно, в котором доступом может воспользоваться локальный процесс 10 минут жизни сертификата всё время, пока прокси запущен
Платформы Windows, macOS, Linux только Linux

Для администратора кластера между ними нет никакой разницы

Оба режима предъявляют один и тот же сертификат, от одного корня, с одним субъектом и одним сроком жизни. Ни одна настройка на стороне кластера не выбирает между ними и не должна ничего знать о выборе. Сказано это прямо потому, что обратное предположение напрашивается само.

Что выбрать

Берите плагин, если у вас нет причины поступить иначе. Он не требует запущенного процесса, работает на всех трёх платформах и даёт более короткое окно.

Локальный прокси имеет смысл там, где отдельное требование запрещает появление приватного ключа в памяти любого процесса, кроме агента, — и где машины сотрудников на Linux. Учитывая оговорку выше, это размен, а не усиление: вы меняете «ключ на десять минут в памяти kubectl» на «открытый петлевой порт всё время работы прокси».

Режим выбирается на самой машине — тем, какую команду запустили. Настройки, которая задавала бы режим всему парку с сервера, пока нет.

Что знать про прокси до внедрения

Только Linux. На macOS и Windows определить, какому пользователю принадлежит подключившийся к петлевому порту процесс, пока нечем, поэтому слушатель там отказывает всем. Отказ честный: петлевой порт достижим для каждого процесса машины, и обслуживать его, не зная вызывающего, нельзя.

HTTP/1.1, и только он. Прокси предлагает клиенту исключительно http/1.1. Причина не в консервативности: под HTTP/2 одно соединение несёт много запросов, а прокси авторизует каждый — вырезать свой служебный токен из потоков, которые он не разбирает, было бы нечем, и токен уехал бы в кластер. Kubernetes обслуживает HTTP/1.1 полностью, а kubectl exec, attach и port-forward в любом случае работают поверх него. Клиент, требующий HTTP/2, получает названный отказ, а не наполовину работающее соединение.

Что это значит для вас: настраивать ничего не нужно, но если какой-то инструмент не работает через прокси, работая напрямую с API-сервером, — сначала проверьте, не требует ли он HTTP/2, и только потом ищите причину в другом месте.

Что дальше