Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Как вы храните пароли для ваших автоматических тестов? (идеи и опыт)

database
test-data
jenkins
Теги: #<Tag:0x00007f7b647ca380> #<Tag:0x00007f7b647ca240> #<Tag:0x00007f7b647ca100>

(Yuka) #1

Народ, а как вы храните пароли?

Во время автоматизированного тестирования приходиться хранить / вводить кучу паролей (юзеров / от DB / etc).

Не хорошо знать ни в репозитории, ни в Jenkins настройках.

Может есть хорошие идеи / опыт?


(Дмитрий Жарий) #2

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

Конечно, существует способы зашифровать пароль… Но, по сути, при желании, имея код или бинарник, шифрующий пароль, взломщик может расшифровать этот пароль (даже в случае Jenkins), так же легко, как если бы он был зашифрован ROT13


(sidelnikovmike) #3

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


(asolntsev) #4

Тест сам генерирует исходные данные (в т.ч. пользователей с паролями), прогоняет, проверяет и удаляет данные. Это единственный правильный способ.


(Mykhailo Poliarush) #5

Поддержу @sidelnikovmike храню в обычном файле конфигураций без всяких шифрований в силу того что пользователи имеют особый статус и держать их в секретность нет смысла. Но если бы надо было скрыть их, то наверное просто подключил бы какую-то библиотеку шифрования (например для питона это https://pythonhosted.org/passlib/) и больше бы не парился, правильно @dzhariy говорит, все равно если очень захотеть можно все сломать и найти.


(Максим Таран) #6

Да, у нас тоже используются специальные пользователи для автоматизации. И отдельные среды.


(Yuka) #7

Специальный пользователь для тестов == пользователь только для чтения, правильно?
Значит если пароли утекут, как-то сможет прочитать данные. Это не очень приятно.

“Тест сам генерирует исходные данные (в т.ч. пользователей с паролями),
прогоняет, проверяет и удаляет данные. Это единственный правильный
способ.” - это значит, что тестовый пользователь имеет права на запись в БД. Тоже не очень хорошо.

Я согласен, что environment для тестирования не должн иметь реальных данных. Т.е. защищать данные не критично. Но, ведь хочется иметь и смок тест для production environment, что б проверять дэплоймент…

У меня просто параноидальные товарищи в отделе секюрити :smile:.

З.Ы. Иногда так классно быть в разных часвых зонах - задал вопрос перед сном, и утром на него уже ответило куча народу!
Спасибо!


(Максим Таран) #8

А, так Вам на проде. :)) Тогда можно использовать ldap, например? У вас же доменная аутентификация?


(Yuka) #9

Это было б слишком просто :smile:. Во время тестов надо использовать многих юзеров (каждый тип юзера имеет разные виды / права внутри систем).

Например, рабочие (не для тестирования) пароли к БД по время деплоймента передаються через специальную (и не бесплатную) систему. Мне не хочется делать тоже самое и для тестирования - слишком сложно и не удобно.

Хочется найти что-то простое, удобное и что б служба безопасно на меня косо не смотрела.


(Максим Таран) #10

Ну, тогда вижу так. По-любому надо создавать специальных пользователей и, например, в качестве хранилища использовать jks прямо из тестов. И доставать из него.


(Yuka) #11

A jks == “Java Keytool keystore”?
Что-то мне кажется, что это не jks :smile:Z, правда?


(Максим Таран) #12

Да, естественно имелся в виду JavaKeyStore :slight_smile:


(Yuka) #13

Спасибо, попробую!


(Sergey Korol) #14

Из всей этой истории мне не понятно вот что… Если у вас там все настолько секьюрно, CI по-идее должен быть закрыт от внешнего мира. Предположу также, что автомейшен тесты живут в своем собственном private репозитории, не являясь частью продакшен кода. Каким же образом кто-либо из вне сможет получить доступ к вашим исходникам и украсть пароли?

Следующий момент. О каком шифровании паролей тестовых юзеров речь, если самые хорошие алгоритмы работают только в одну сторону? Но при авторизации вы ведь вводить должны не encrypted вариант. :wink: А использовать алгоритм “лишь бы зашифровать”, то это как мертвому - припарка.

По теме: app db креденшалы храню в maven профайлах. Переключаюсь через -Ddb=qa/dev/prod. Пароли тестовых юзеров - в независимой закрытой автомейшен БД в незашифрованном виде. Сами тесты собираются на выделенном закрытом CI. Сорсы естественно живут отдельно от продакшен кода.

П.С. Вам также советую не морочить голову ни себе, ни другим.


(asolntsev) #15

Мы, наверное, живём в каких-то разных реалиях. Для нас наоборот естественно хранить тесты вместе с кодом. Чтобы их мог и запустить, и исправить, и дополнить любой желающий.


(Sergey Korol) #16

Я надеюсь речь идет не о unit / integration тестах? В случае с UI тестами - зачем мне подключать автомейшен депенденси в продакшен код? Ну и обратная ситуация: зачем QA-инженерам стягивать локально громандную многомодульную систему для запуска автотестов? В случае распределенных тимов, никому не нужен лишний код. Да и не все его готовы предоставить.


(Максим Таран) #17

Согласен. Нафиг в бою не нужны тесты.


(Yuka) #18

Конечно CI закрыт от внешнего мира. И тесты живут в отдельном репозитории и данные в тестовой базе исключительно тестовые… Но секьюрити всё равно бдят и не дают спокойно жить :smile:

Как показывает опыт, взлом не происходит только из-за одной дырочки, обычно надо несколько. Поэтому и хотелось бы закрыть все возможные (дырочки).


(asolntsev) #19

Речь идёт обо всех тестах. Очень удобно хранить в одном репозитории и код, и тесты - в первую очередь тем, что разработчики могут при желании запустить тесты перед коммитом. А также исправлять и дописывать тесты. Ну, а система для запуска автотестов просто не должна быть громадной и многомодульной. Тесты по определению должны быть простыми.

Но да, мы просто, наверное, в разных мирах вращаемся. Видимо, у вас всё совсем по-другому.


(Sergey Korol) #20

У нас аутсорс, а не продуктовая компания. Разрабатываемый проект заточен под Java 7, перехода на 8 не планируется. REST - через Jersey 1.x.

А теперь автомейшен… У меня все уже давно переведено на 8ку. REST via Jersey 2.x. Уже по этим 2м причинам наши тесты чисто физически не совместимы с кодом продукта. А даунгрейдить все под почти мертвые технологии смысла не вижу.