Создание первого администратора

Сервер администрирует сам себя. Нет ни заранее созданного пароля, который нужно искать в логе, ни команды create-admin: первый администратор создаётся из браузера, один раз.

1. Откройте /admin в только что подготовленном развёртывании, например http://localhost:3000/admin.

2. Экран Create the first super admin запрашивает адрес e-mail и пароль длиной не менее двенадцати символов. Учётная запись попадает в зарезервированный бакет пользователей «Administrators», становится членом группы Super administrators — группы, члены которой администрируют весь экземпляр, — и получает личную группу, как любой другой администратор.

3. Отправьте форму, затем войдите с этими учётными данными.

Маршрут настройки закрывается, как только в Super administrators появляется активный член, и с этого момента отвечает 409 already_initialized. /admin становится страницей входа. Следующие администраторы создаются в консоли на странице Administrators кнопкой New administrator, с адресом e-mail и паролем не короче двенадцати символов. Суперадминистратор может также открыть регистрацию на вкладке Sign-in этой страницы, чтобы люди регистрировались сами, или подключить провайдера идентификации вашей организации в разделе Identity providers. Новый администратор никогда не становится суперадминистратором, каким бы путём он ни появился: это право суперадминистратор выдаёт отдельно, пунктом Make super administrator… в меню учётной записи. (Членство в обычной группе, в свою очередь, предлагается приглашением по e-mail.) Если вы видите экран настройки в развёртывании, где администраторы должны быть, это стоит расследовать: значит, в коллекции учётных записей, которую читает этот сервер, их нет.

Осторожно

/admin — экран входа, открытый в интернет. Процесс первого запуска никак не аутентифицирован, и иначе быть не может, ведь ни одной учётной записи ещё нет. Поэтому создайте первого администратора сразу после того, как развёртывание поднимется, и не оставляйте доступный извне и неподготовленный экземпляр без присмотра.

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

Администраторы входят через собственный issuer этого сервера

Вход в консоль — это поток authorization code OpenID Connect к тому самому серверу, который консоль администрирует, через собственный (first-party) клиент admin-panel, который создаёт db:setup. Нет ни второго хранилища паролей, ни отдельного пути аутентификации только для администраторов: администратор — это конечный пользователь в зарезервированном бакете администраторов, а то, что admin API позволяет ему делать, следует из групп, в которых он состоит.

Отсюда два следствия, и оба встречаются на практике:

• Redirect URI клиента из начальных данных — $ISSUER/admin/callback; он записывается один раз, при первой вставке клиента. Если ISSUER изменился после начального заполнения, вход перенаправляет на URI, которого у клиента нет, и завершается ошибкой; повторный запуск db:setup этого не исправляет. Что делать, см. в предупреждении в руководстве по Compose.
• Без начальных данных консоль недоступна. Если db:setup ни разу не запускался, /admin/login перенаправляет на /auth с client_id, которому не соответствует ни один клиент.

Включите второй фактор

Бакет администраторов — это дверь с паролем в публичном интернете, поэтому мы советуем первым делом потребовать на нём приложение-аутентификатор. В консоли перейдите на страницу Administrators (только для суперадминистраторов), откройте вкладку Sign-in, включите Require an authenticator app for password sign-in и сохраните. Сначала консоль покажет, у скольких администраторов ещё нет аутентификатора, и попросит подтвердить.

После этого для входа нужен шестизначный код в дополнение к паролю. Включение никого не блокирует: администраторы без аутентификатора подключат его при следующем входе. Это касается и агента, который входит через зарезервированный клиент admin-mcp, создаваемый database/mongodb.ts, — он проходит через ту же дверь. Администраторы, которые входят через провайдера идентификации, вместо этого проходят второй фактор этого провайдера: требование касается только входа по паролю.

Это важнее, чем может показаться. Неудачные попытки ввода пароля считаются по паре «бакет и адрес e-mail», и адрес, достигший лимита, на какое-то время получает отказ. Бакет, требующий одноразовый код, остаётся на первом окне блокировки, сколько бы раз она ни срабатывала, — так задумано: угаданный пароль там никого не впускает. Кроме того, у администраторов нет самостоятельного сброса пароля, которым можно было бы обойти блокировку. По-настоящему прочной эту дверь делает второй фактор, а не троттлинг. Собственные настройки троттлинга — loginThrottle.failureCap, loginThrottle.windowSeconds и loginThrottle.windowCeilingSeconds в справочнике настроек.

Что доступно администратору

Суперадминистраторская часть консоли охватывает сам экземпляр: настройки сервера, ключи подписи, SMTP, учётные записи администраторов и хранилище сбоев. Быть суперадминистратором — значит состоять в зарезервированной группе Super administrators; членство выдаётся и отзывается отдельными операциями (Make super administrator… и Withdraw super administration… на странице Administrators или admin_super_grant и admin_super_withdraw для агента), а последнего активного члена нельзя ни исключить, ни деактивировать. Любой другой администратор создаёт проекты, бакеты и группы, приглашает людей в свои обычные группы по e-mail и читает журнал аудита и страницу Usage своих групп. Владение определяется группой: доступ к контейнеру даёт членство в группе, которой он принадлежит.

Каждое действие, меняющее состояние, — как в консоли, так и со стороны агента — записывается в журнал аудита, допускающий только добавление, ещё до самого изменения, с указанием исполнителя, действия и объекта. Хранилище не предоставляет операций обновления или удаления.

Если вы нашли проблему безопасности, а не конфигурации, политика раскрытия уязвимостей и контакты проекта находятся на странице безопасности.