Регистрация Войти
Рейтинг:0
avatar Server

Custom root cert for kubeconfig files

флаг jp
Chris G.

Running kubeadm init phase certs apiserver --config kubeadm.yaml

Is it possible to have multiple/custom root certificate to be used for group of users/kubectl/config files?

I am asking because, I would like to give access, on a per project basis - and then afterwards remove the custom root cert - but keep the the "original" root cert for special kubectl administrators.

I have seen that you can use ssh tunneling as a first line of defence, to protect the root certificate public key. But you still need to distribute the public signed cert, even it is behind the ssh public private key. Therefore maybe there is a way around using ssh tunneling - and putting a custom cert in certificatesDir: /etc/kubernetes/pki?

kubeadm.yaml

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

I know you can use --insecure-skip-tls-verify in config file, but it seems like a bad idea.

53
0 + 0
Рейтинг:1
avatar Server
флаг in
mdaniel

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

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

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

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

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

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

0 + 0
флаг jp
Chris G.
Спасибо за ответ - думаю, я воспользуюсь вашей рекомендацией, используя OpenID (OIDC). Я попытаюсь объединить этот https://github.com/micahhausler/k8s-oidc-helper с github https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps.
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.