Могу ли я заменить файл client-ca, чтобы сделать недействительными всех пользователей в kubernetes?

Question

При настройке нашего кластера мы используем kubespray, который создает для меня пользователя kubernetes-admin.Я считаю, что код здесь .

По какой-то причине сейчас этот admin.conf просочился всем нашим разработчикам, и мне как-то нужно отозвать его.

Что (Я думаю) Я понимаю:

В нашем кластере kubernetes мы используем x509 для аутентификации наших пользователей.Для наших пользователей мы создаем закрытый ключ, затем создаем CSR с этим ключом и подписываем его с помощью client-ca-file и ключа из нашей установки kubernetes.Например:

openssl genrsa -out $K8S_USER-key.pem 2048
openssl req -new -key $K8S_USER-key.pem -out $K8S_USER.csr -subj "/CN=$K8S_USER"
openssl x509 -req -in $K8S_USER.csr -CA $cert_dir/ca.pem -CAkey $cert_dir/ca-key.pem -set_serial $SERIAL -out $K8S_USER.pem -days $DAYS

Я предполагаю, что то же самое было сделано для пользователя kubernetes-admin, и я предполагаю, что когда я изменяю client-ca-file, admin.conf больше не может использоваться для использования API kubernetes.

Это правильно?Это изменение client-ca-file сделает недействительным kubernetes-admin?

. Я также предполагаю, что мне нужно заново создать все мои учетные записи служб, поскольку они также будут признаны недействительными.

РЕДАКТИРОВАТЬ: Итак, я потратил некоторыевремя создания нового сертификата CA, а затем выдачи новых сертификатов для моего пользователя и kube-apiserver.Не уверен, что перезапуска модулей apiserver было достаточно, хотя.Мой пользователь отклонен как Unable to connect to the server: x509: issuer name does not match subject from issuing certificate.Это не имеет большого смысла для меня, хотя.Когда я подключаюсь к модулю apiserver через exec и проверяю сертификат apiserver, он имеет того же эмитента, что и мой сертификат пользователя kubeconfig.

Answer 1

Изменение client-ca-file не приведет к аннулированию kubernetes-admin.

Ссылаясь на ваш случай:

Во время создания файла конфигурации для генерации запроса на подпись сертификата вам необходимо (CSR подставить значения, отмеченные угловыми скобками (например, <<strong> MASTER_IP >), с реальными значениями, прежде чем сохранять их в файл (например, csr). .conf). Значение для MASTER_CLUSTER_IP - это IP-адрес кластера служб для сервера API. Я предполагаю, что вы используете cluster.local в качестве имени домена DNS по умолчанию.

Добавили ли вы те же параметры в параметры запуска сервера API?

Отправьте CSR в CA, как и в случае с любым CSR, но с опцией -selfsign. Это требует, чтобы ваша структура каталогов CA была подготовлена ​​в первую очередь, что вам придется делать в любом случае, если вы хотите настроить свой собственный CA. Вы можете найти учебник по этому здесь , например. Отправка запроса может быть выполнена следующим образом:

ca -selfsign -keyfile dist/ca_key.pem -in ca_csr.pem -out dist/ca_cert.pem \
    -outdir root-ca/cert -config openssl/ca.cnf

Клиентский узел может отказаться признать самозаверяющий сертификат CA действительным. Для непроизводственного развертывания или для развертывания, которое выполняется за брандмауэром компании, вы можете распространять самозаверяющий сертификат CA всем клиентам и обновлять локальный список для допустимых сертификатов.

На каждом клиенте выполните следующие операции:

$ sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt

$ sudo update-ca-certificates

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
done.

Сделать утечку сертификата бесполезной - значит заменить ЦС в кластере. Это потребует перезагрузки кластера, хотя. И это потребует переиздания всех сертификатов. Вам придется заново создать служебную учетную запись.

Чтобы аннулировать просочившиеся токены, просто удалите секрет, соответствующий токену пользователя. Запомните дату окончания действия сертификата, которую вы добавили.

Надеюсь, это поможет.