Комментарии 3
У сертификата есть дата окончания валидности. Раскройте эту тему подробнее:
— обновление сертификата у клиента
— обновление сертификата внутри самого куба.
Я не админ, мне непонятно какой ключ используется самим сервером для подписания CSR во время команды «kubectl certificate approve mycsr».
В вашем примере сертификат валиден 1 год.
А если в кубере 3х месячный Let`encrypt?
— обновление сертификата у клиента
— обновление сертификата внутри самого куба.
Я не админ, мне непонятно какой ключ используется самим сервером для подписания CSR во время команды «kubectl certificate approve mycsr».
В вашем примере сертификат валиден 1 год.
А если в кубере 3х месячный Let`encrypt?
Прежде чем ответить, сделаю важную, на мой взгляд, ремарку. В производственном кластере не стоит использовать сертификаты для предоставления и разграничения доступа пользователям. Основных причин тому две — в RBAC нет понятия запретов, и Kubernetes не поддерживает CRL. Т.е., если условный Дейв перейдёт в другой отдел, но оставит себе сертификат, то он будет иметь все права, данные ему ранее, до ротации сертификата CA или истечения срока действия. Если по каким-то причинам нет возможности прикрутить стороннюю систему IAM, то лучше остановиться на JWT.
Обновление сертификата у клиента выполняется, как правило, выдачей ему нового, с последующей заменой соответствующих полей в файле конфигурации (kubeconfig).
Обновление сертификата внутри Kubernetes — это продление существующего (на том же закрытом ключе делается новый запрос с расширенным сроком) или создание нового, типовая задача, не уникальная для k8s. Затем нужно поменять ключ в параметре "--client-ca-file" службы kube-api-server всех инстанций управляющих нод. По-моему, этот параметр поддерживает сразу несколько сертификатов, через запятую, на случай, когда требуется обеспечить аутентификацию одновременно подписанным старым и новым CA. Если применяется описанный в статье механизм CSR, ключ также меняется в службе kube-controller-manager (--cluster-signing-cert-file и --cluster-signing-key-file). В kubeadm, вроде, есть встроенный функционал, автоматизирующий процедуру обновления сертификатов.
Если использовать 3-месячный сертификат, очевидно, придётся выполнять такие действия раз в 1,5-2 месяца. Но, т.к. проверка выполняется исключительно внутри Kubernetes заданным CA-сертификатом, проще использовать для этих целей самоподписанный. Let's Encrypt стоит оставить для задач, где идёт взаимодействие с клиентом через браузер (веб-интерфейс api-server, pod-ы, ingress и т.д.).
Рекомендую обратиться к официальной документации Kubernetes, например:
* kubernetes.io/docs/setup/best-practices/certificates
* kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster
Также нужно изучить конкретные компоненты кластера, в частности, упомянутые kube-api-server и kube-controller-manager. Kubernetes весьма сложен, придётся потратить немало усилий, чтобы разобраться в его внутренностях. Ну или оставить это админам.
Обновление сертификата у клиента выполняется, как правило, выдачей ему нового, с последующей заменой соответствующих полей в файле конфигурации (kubeconfig).
Обновление сертификата внутри Kubernetes — это продление существующего (на том же закрытом ключе делается новый запрос с расширенным сроком) или создание нового, типовая задача, не уникальная для k8s. Затем нужно поменять ключ в параметре "--client-ca-file" службы kube-api-server всех инстанций управляющих нод. По-моему, этот параметр поддерживает сразу несколько сертификатов, через запятую, на случай, когда требуется обеспечить аутентификацию одновременно подписанным старым и новым CA. Если применяется описанный в статье механизм CSR, ключ также меняется в службе kube-controller-manager (--cluster-signing-cert-file и --cluster-signing-key-file). В kubeadm, вроде, есть встроенный функционал, автоматизирующий процедуру обновления сертификатов.
Если использовать 3-месячный сертификат, очевидно, придётся выполнять такие действия раз в 1,5-2 месяца. Но, т.к. проверка выполняется исключительно внутри Kubernetes заданным CA-сертификатом, проще использовать для этих целей самоподписанный. Let's Encrypt стоит оставить для задач, где идёт взаимодействие с клиентом через браузер (веб-интерфейс api-server, pod-ы, ingress и т.д.).
Рекомендую обратиться к официальной документации Kubernetes, например:
* kubernetes.io/docs/setup/best-practices/certificates
* kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster
Также нужно изучить конкретные компоненты кластера, в частности, упомянутые kube-api-server и kube-controller-manager. Kubernetes весьма сложен, придётся потратить немало усилий, чтобы разобраться в его внутренностях. Ну или оставить это админам.
Добавлю, что про expiration сертификатов есть статья habr.com/ru/company/southbridge/blog/465733
В целом, если проэкспайрятся сертификаты в kubernetes он просто перестанет работать. Подробнее о сертификатах
kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests
В целом, если проэкспайрятся сертификаты в kubernetes он просто перестанет работать. Подробнее о сертификатах
kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как предоставить доступ к кластеру Kubernetes с помощью клиентского сертификата: простое руководство