Настройте взаимную аутентификацию в Kubernetes - PullRequest
Новая
       15

Настройте взаимную аутентификацию в Kubernetes

0 голосов
/ 14 апреля 2020

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

Итак вот проблема

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

Я сомневаюсь, обязательно ли при создании сертификата указывать полное доменное имя в поле Common Name, или у нас есть обходной путь для этого.

TIA

1 Ответ

2 голосов
/ 14 апреля 2020

Вы можете предоставить Полное имя домена (FQDN) в Альтернативное имя субъекта вместо общего имени. Альтернативное имя субъекта не имеет ограничения в 64 символа.

Общее правило заключается в том, что домен проверяется на предмет всех сетей SAN и общего имени. Если домен там найден, то сертификат в порядке для подключения.

RF C 5280 , в разделе 4.1.2.6 говорится "Имя субъекта МОЖЕТ быть перенесено в поле субъекта и / или расширение subjectAltName ". Это означает, что имя домена должно быть проверено как по расширению SubjectAltName, так и по свойству Subject (а именно, это параметр общего имени) сертификата. Эти два места дополняют друг друга, а не дублируют его. И SubjectAltName является подходящим местом для добавления дополнительных имен, таких как www.domain.com или www2.domain.com

Согласно RF C 6125 , опубликованному в 2011 году, валидатор должен сначала проверить SAN и если SAN существует, то CN не должен проверяться. Обратите внимание, что RF C 6125 является относительно новым и все еще существуют сертификаты и CA, которые выпускают сертификаты, которые включают в себя «основное» доменное имя в CN и альтернативные доменные имена в SAN. Т.е., исключая CN из проверки, если SAN присутствует, вы можете отказать в каком-либо другом действительном сертификате

...