Последний шаг в создании пользовательских сертификатов cockroachdb на Kubernetes (GKE) - PullRequest
0 голосов
/ 07 сентября 2018

У меня проблемы с последним этапом создания пользовательских сертификатов для использования с клиентом NodeJS pg для доступа к защищенному CockroachDB, работающему на GKE. (все работает нормально, используя клиентский ключ пользователя root и сертификат, но я не хочу использовать root для доступа к pg).

Каталог контейнера / cockroach-certs выглядит следующим образом

ca.crt  client.root.crt  client.root.key

и

kubectl exec -it cockroachdb-client-secure -- ./cockroach  --certs-dir=/cockroach-certs cert list

показывает

+-----------------------+------------------+-----------------+------------+--------------+-------+
|         Usage         | Certificate File |    Key File     |  Expires   |    Notes     | Error |
+-----------------------+------------------+-----------------+------------+--------------+-------+
| Certificate Authority | ca.crt           |                 | 2023/09/03 | num certs: 1 |       |
| Client                | client.root.crt  | client.root.key | 2023/09/03 | user: root   |       |
+-----------------------+------------------+-----------------+------------+--------------+-------+

Я использовал таракана client-secure.yaml (https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/client-secure.yaml) - тот же, что и для настройки CSR для root - но изменил имя пользователя на xyz (которое было добавлено в качестве пользователя в БД). Это успешно сгенерировало CSR для xyz, который я тогда одобрил.

default.client.xyz                               8m        system:serviceaccount:default:cockroachdb   Approved,Issued

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

default.client.xyz                Opaque                                2         9m

Проблема в том, что в списке сертификатов не отображаются client.xyz.key или client.xyz.crt, и они не находятся в каталоге / cockroach-certs. Если я извлечу их из секретного файла default.client.xyz и скопирую туда вручную, они появятся в списке сертификатов, но не будут назначены конкретному пользователю.

Документы о тараканах используют "сертификат таракана" для создания пользователя, но не показывают конкретный процесс при использовании kubernetes. Поэтому я пропускаю этот последний фрагмент головоломки - почему client-secure.yaml работает через весь процесс с -user = root, но пропускает последний шаг с -user = xyz, и какой шаг я пропускаю?

.... Добавлена ​​дополнительная информация Контейнер утверждает, что записал файлы сертификата, но на самом деле их там нет.

$ kubectl logs fidserver-csr  -c init-certs

+ /request-cert '-namespace=default' '-certs-dir=/cockroach-certs' '-type=client' '-user=fidserver' '-symlink-ca-from=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt'
2018/09/07 15:32:11 Looking up cert and key under secret default.client.fidserver
W0907 15:32:11.700733       1 client_config.go:529] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
2018/09/07 15:32:11 Writing cert and key to local files
wrote key file: /cockroach-certs/client.fidserver.key
wrote certificate file: /cockroach-certs/client.fidserver.crt
symlinked CA certificate file: /cockroach-certs/ca.crt -> /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

.... Обновлено, чтобы повторить попытку в другом каталоге сертификатов - на самом деле файлы не были записаны, хотя в журнале утверждается, что они были. Симлинка тоже не было.

+ /request-cert '-namespace=default' '-certs-dir=/cockroach-client-certs' '-type=client' '-user=fidserver' '-symlink-ca-from=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt'
2018/09/08 09:35:56 Looking up cert and key under secret default.client.fidserver
W0908 09:35:56.160525       1 client_config.go:529] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
2018/09/08 09:35:56 Secret default.client.fidserver not found, sending CSR
Sending create request: default.client.fidserver for 
Request sent, waiting for approval. To approve, run 'kubectl certificate approve default.client.fidserver'
2018-09-08 09:36:26.718183601 +0000 UTC m=+30.564697651: waiting for 'kubectl certificate approve default.client.fidserver'
2018-09-08 09:36:56.718422397 +0000 UTC m=+60.564936446: waiting for 'kubectl certificate approve default.client.fidserver'
2018-09-08 09:37:26.718657743 +0000 UTC m=+90.565171864: waiting for 'kubectl certificate approve default.client.fidserver'
2018-09-08 09:37:56.718959817 +0000 UTC m=+120.565473905: waiting for 'kubectl certificate approve default.client.fidserver'
CSR approved, but no certificate in response. Waiting some more
request default.client.fidserver Approved at 2018-09-08 09:38:00 +0000 UTC
  reason:   KubectlApprove
  message:  This CSR was approved by kubectl certificate approve.
2018/09/08 09:38:00 Storing cert and key under secret default.client.fidserver
2018/09/08 09:38:01 Writing cert and key to local files
wrote key file: /cockroach-client-certs/client.fidserver.key
wrote certificate file: /cockroach-client-certs/client.fidserver.crt
symlinked CA certificate file: /cockroach-client-certs/ca.crt -> /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

Теперь зарегистрировано как проблема с тараканом. https://github.com/cockroachdb/cockroach/issues/29968

1 Ответ

0 голосов
/ 10 сентября 2018

Это было отлажено в выпуске github .

Сертификат и ключ, извлеченные контейнером инициализации request-cert, - это сертификаты для пользователя, запрошенного с помощью аргумента --user.

Это означает, что контейнер будет иметь доступ только к одному набору учетных данных клиента. Том также не будет обновляться другими сертификатами, поскольку это делается только во время инициализации.

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

  • request-cert начальный контейнер с --user=<desired user>
  • контейнер, использующий клиентские сертификаты для <desired user> в /cockroach-certs
...