Безопасно передавать учетные данные в conda для доступа к корпоративным каналам прокси - PullRequest
Новая
       10

Безопасно передавать учетные данные в conda для доступа к корпоративным каналам прокси

1 голос
/ 13 марта 2020

Не уверен, что это действительно принадлежит SO, пожалуйста, укажите более подходящее сообщество, если таковое имеется ...

Я пытаюсь получить доступ к conda репозиториям через корпоративный прокси-сервер, размещенный на Nexus OSS, с рабочей станции Windows 10. Соединение работает нормально, но требует, чтобы пользователь сохранил свои учетные данные в файле .condarc: 

channels
 - https://<user>:<password>@<my_corp_proxy>/<repo1>/
 - https://<user>:<password>@<my_corp_proxy>/<repo2>/

Не только пароль хранится в файле в незашифрованном виде: он запрашивается для пользователя при возникновении ошибки и, более хитроумно, он также сохраняется в файле .json, сообщающем о загрузке пакета в каталоге conda-meta environment. Это известная проблема в conda.

Я чувствую очень неудобно из-за необходимости хранить мой пароль на виду, особенно когда мы используем аутентификацию LDAP , Я ищу способ попросить conda получить учетные данные более безопасным способом , но до сих пор, после моих многочисленных исследований по inte rnet, я не смог их найти.

Я пытался сохранить свои учетные данные в Windows Диспетчер учетных данных , в разделе Generi c Учетные данные . git:https://<corporate-gitlab-server>, кажется, работает для git (был добавлен git при первом подключении), поэтому я попробовал следующее для conda: 

conda:https://<corporate-nexus-repo>
miniconda3:https://<corporate-nexus-repo>
python:https://<corporate-nexus-repo>

Ни одна из вышеуказанных конфигураций, кажется, не понимается conda. Итак, вот мы:

  • Как хранить свои учетные данные в Windows Диспетчер учетных данных , чтобы conda мог их получить? Я не нашел подробной документации о том, как использовать эту функцию.
  • Если это невозможно, есть какой-нибудь легко выполнимый обходной путь (это должно быть то, что все конечные пользователи могут управлять в разумное количество шагов)?

1 Ответ

0 голосов
/ 16 марта 2020

Windows GCM (Git -Credential-Manager-for- Windows) позволяет кэшировать учетные данные, используемые Git для доступа к удаленному репозиторию: это не будет работать для других тип удаленных сервисов (например, корпоративный прокси).

На работе мы всегда используем локальный прокси (который перенаправляет на фактический корпоративный прокси, используя учетные данные текущего сеанса): genotrance / px (существует px.exe, предварительно скомпилированный для Windows)

Px - прокси-сервер HTTP (s), который позволяет приложения для аутентификации через прокси-сервер NTLM или Kerberos, обычно используемые в корпоративных развертываниях, без необходимости иметь дело с фактическим рукопожатием.

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

Таким образом, учетные данные не когда-либо хранится локально.

OP Romain Reboulleau выбрал другой подход в комментариях :

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

...