Вопросы Теги

Пользовательский корневой сертификат для файлов kubeconfig

Работаетkubeadm init phase certs apiserver --config kubeadm.yaml

Возможно ли использовать несколько/настраиваемых корневых сертификатов для группы пользователей/kubectl/файлов конфигурации?

Я спрашиваю, потому что я хотел бы предоставить доступ для каждого проекта -, а затем удалить собственный корневой сертификат -, но оставить «исходный» корневой сертификат для специальных администраторов kubectl.

Я видел, что вы можете использовать ssh-туннелирование в качестве первой линии защиты, чтобы защитить открытый ключ корневого сертификата. Но вам все равно нужно распространять общедоступный подписанный сертификат, даже если он находится за открытым закрытым ключом ssh. Поэтому, может быть, есть способ использовать туннелирование ssh -и поместить собственный сертификат в certificatesDir: /etc/kubernetes/pki?

kubeadm.yaml

apiServer:
  extraArgs:
    authorization-mode: Node,RBAC
  timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta1
certificatesDir: /etc/kubernetes/pki

Я знаю, что вы можете использовать --insecure-skip-tls-verifyв файле конфигурации, но это кажется плохой идеей.

0
задан 13 October 2021 в 21:20
1 ответ

Можно ли использовать несколько/настраиваемых корневых сертификатов для групп пользователей/kubectl/файлов конфигурации?

Нет, существует только один «корневой» сертификат, поэтому он и называется корневым.

Тем не менее, x509 представляет собой цепочкудоверия, что означает, что вполне возможно выдавать подчиненные ЦС под этим корнем, а затем выдавать пользовательские сертификаты в этих ЦС, выбирая удаление подчиненных ЦС по завершении проекта, который осиротит все эти листовые сертификаты. Имейте в виду, что, насколько мне известно, изменение сертификатов или их цепочки требует перезапуска плоскости управления, поскольку она не выполняет горячую перезагрузку этих файлов сертификатов. Я полагаю, что для этого есть проблема GitHub, как и для всех остальных 15 000 из них.

Другой вариант, в зависимости от ваших потребностей, заключается в предоставлении краткосрочной аренды для пользовательских сертификатов, чтобы процесс «отзыва» не был настолько сильно изменяет цепочку доверия x509, что просто не может повторно выдать учетные данные.Это ближе к Hashicorp Vault и школе мысли Let's Encrypt

. Я лично реализовал второй вариант (используя Vault), но я считаю, что первый вариант возможен, потому что apiserver использует цепочки x509 для аутентификации некоторых своих компонентов в кластере. , поэтому я не понимаю, почему вы не можете аналогичным образом воспользоваться этим механизмом.

Я знаю, что это не то, о чем вы просили, но использование x509 для временной аутентификации, подобное этому, ведет к краху, потому что -- как вы переживание - обе стороны, выдача и отзыв, являются огромной болью.Если он вообще доступен для вас, механизм аутентификации OIDCгораздо проще понять, и kubectlимеет более или менее встроенную поддержку для него

.
1
ответ дан 14 October 2021 в 03:53

Теги

Похожие вопросы