Не удалось аутентифицировать вас из Ldapmain, потому что «Недопустимые учетные данные для <username>» - Gitlab Community Edition, установленный через Helm Chart - PullRequest
Новая
       49

Не удалось аутентифицировать вас из Ldapmain, потому что «Недопустимые учетные данные для <username>» - Gitlab Community Edition, установленный через Helm Chart

1 голос
/ 30 октября 2019

У меня установлен Gitlab CE с использованием Helm , но наши пользователи AD не могут войти на платформу. В пользовательском интерфейсе входа отображается следующая ошибка: Could not authenticate you from Ldapmain because "Invalid credentials for userX" Неверные учетные данные для пользователя (но учетные данные в порядке!)

Установка : 

helm upgrade --install gitlab gitlab/gitlab --namespace my-ns --tiller-namespace tiller-ns  --timeout 600 --set global.edition=ce --set global.hosts.domain=example.com --set global.hosts.externalIP=<ExternalIPAddressAllocatedToTheNGINXIngressControllerLBService> --set nginx-ingress.enabled=false --set global.ingress.class=mynginx-ic --set certmanager.install=false --set global.ingress.configureCertmanager=false --set gitlab-runner.install=false --set prometheus.install=false --set registry.enabled=false --set gitlab.gitaly.persistence.enabled=false --set postgresql.persistence.enabled=false --set redis.persistence.enabled=false --set minio.persistence.enabled=false --set global.appConfig.ldap.servers.main.label='LDAP' --set global.appConfig.ldap.servers.main.host=<IPAddressOfMyDomainController> --set global.appConfig.ldap.servers.main.port='389' --set global.appConfig.ldap.servers.main.uid='sAMAccountName' --set global.appConfig.ldap.servers.main.bind_dn='CN=testuser,OU=sampleOU3,OU=sampleOU2,OU=sampleOU1,DC=example,DC=com' --set global.appConfig.ldap.servers.main.password.secret='gitlab-ldap-secret' --set global.appConfig.ldap.servers.main.password.key='password'

Примечания :
-Я ранее устанавливал свой собственный NGINX Ingress Controller отдельно: 

helm install stable/nginx-ingress --name nginx-ingress --namespace my-ns --tiller-namespace tiller-ns --set controller.ingressClass=mynginx-ic

-Я ранее создал секрет с паролем для пользователя, настроенного какbind_dn ('CN = testuser, OU = sampleOU3, OU = sampleOU2, OU = sampleOU1, DC = пример, DC = com'). Пароль кодируется с использованием base64, как указано в документации

Файл: gitlab-ldap-secret.yaml 

apiVersion: v1  
kind: Secret  
metadata:  
 name: gitlab-ldap-secret  
data:  
 password: encodedpass-blablabla

- Вместо предоставления всех этих параметров вВ командной строке во время установки диаграммы я попытался просто настроить все в различных значениях. yaml, который предоставляет эта диаграмма Gitlab Helm , но это просто показалось документировать здесь таким образом, для целей воспроизведения.

-Я попытался добавить эти параметры, не повезло: 

--set global.appConfig.ldap.servers.main.encryption='plain'  
--set global.appConfig.ldap.servers.main.base='OU=sampleOU1,DC=example,DC=com'

-Чтобы сделать его еще проще, мы не рассматриваем постоянство для любого компонента. Вот почему все они установлены в false: 

--set gitlab.gitaly.persistence.enabled=false  
--set postgresql.persistence.enabled=false  
--set redis.persistence.enabled=false  
--set minio.persistence.enabled=false

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

-Я проверил с помощью моего системного администратора, и мы используем обычный 389 в Active Directory. Нет шифрования

Мое окружение 

kubectl.exe version  
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.1", GitCommit:"4485c6f18cee9a5d3c3b4e523bd27972b1b53892", GitTreeState:"clean", BuildDate:"2019-07-18T09:18:22Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"windows/amd64"}  
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.1", GitCommit:"4485c6f18cee9a5d3c3b4e523bd27972b1b53892", GitTreeState:"clean", BuildDate:"2019-07-18T09:09:21Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}  

helm version  
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}  
Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}  

helm ls --tiller-namespace tiller-ns  
NAME                    REVISION        UPDATED                         STATUS          CHART                   APP VERSION     NAMESPACE
gitlab                  1               Tue Oct 29 18:16:06 2019        DEPLOYED        gitlab-2.3.7            12.3.5          my-ns

kubectl.exe get nodes
NAME                                    STATUS   ROLES    AGE     VERSION
kubernetes01.example.com                Ready    master   102d    v1.15.1
kubernetes02.example.com                Ready    <none>   7h16m   v1.15.1
kubernetes03.example.com                Ready    <none>   102d    v1.15.1
kubernetes04.example.com                Ready    <none>   11d     v1.15.1

После установки этой диаграммы все работает нормально: 

kubectl.exe get pods
NAME                                                   READY   STATUS      RESTARTS   AGE
gitlab-gitaly-0                                        1/1     Running     0          65m
gitlab-gitlab-exporter-5b649bfbb-5pn7q                 1/1     Running     0          65m
gitlab-gitlab-shell-7d9497fcd7-h5478                   1/1     Running     0          65m
gitlab-gitlab-shell-7d9497fcd7-jvt9p                   1/1     Running     0          64m
gitlab-migrations.1-gf8jr                              0/1     Completed   0          65m
gitlab-minio-cb5945f79-kztmj                           1/1     Running     0          65m
gitlab-minio-create-buckets.1-d2bh5                    0/1     Completed   0          65m
gitlab-postgresql-685b68b4d7-ns2rw                     2/2     Running     0          65m
gitlab-redis-5cb5c8b4c6-jtfnr                          2/2     Running     0          65m
gitlab-sidekiq-all-in-1-5b997fdffd-n5cj2               1/1     Running     0          65m
gitlab-task-runner-5777748f59-gkf9v                    1/1     Running     0          65m
gitlab-unicorn-764f6548d5-fmggl                        2/2     Running     0          65m
gitlab-unicorn-764f6548d5-pqcm9                        2/2     Running     0          64m

Теперь, если я попробуючтобы войти с пользователем LDAP, я получаю ошибку, упомянутую ранее. Если я захожу внутрь стручка единорога, я вижу следующие сообщения в /var/log/gitlab/production.log: Production.log

Чего мне не хватает? Нужно ли что-то настраивать? Я настроил все параметры для аутентификации LDAP, упомянутые здесь , но все же у меня возникают проблемы при попытке аутентификации.

Извините, но я новичок в Gitlab и всех его внутренних компонентах. Кажется, я не могу найти, где редактировать этот файл, например: /etc/gitlab/gitlab.rb ( в какой модуль мне следует войти? Я буквально ввел каждый из них и не нашел этот файл конфигурации ). Кроме того, я заметил, что в некоторых документах говорится, что некоторые диагностические инструменты могут быть выполнены, например, gitlab-rake gitlab:ldap:check, или такие утилиты, как gitlab-ctl reconfigure, но опять же ... где их запускать ?? На стручке единорога? gitlab-оболочка? Я заметил, что на различных страницах документации Gitlab есть ссылки на некоторые из этих инструментов для устранения неполадок, но я не думаю, что эта диаграмма соответствует той же архитектуре.

Я посмотрел этот пост , например, потому чтокажется, та же проблема, но я не могу найти /etc/gitlab/gitlab.rb

Любая помощь будет высоко ценится. Прошло пару недель с тех пор, как я занимался этим вопросом.

...