Атлас MongoDB: схема контроля доступа
После недавнего перехода между Compose и mLab я наконец остановился на Mongo Atlas. Atlas - недавно выпущенный конкурент в мире поставщиков услуг Mongo, размещаемых и управляемых в облаке. Самым большим преимуществом, с первого взгляда, является то, что он создан и поддерживается командой MongoDB.
В Atlas MongoDB есть много интересных аспектов, но я хотел сосредоточиться на одном конкретном аспекте: Контроль доступа.
Неправильный путь
После создания учетной записи в Mongo Atlas вам предоставляется возможность создавать «Кластеры» (единого пакета развертывания базы данных не существует). При этом вы создаете несколько баз данных, одну первичную, а затем различные вторичные экземпляры.
Моя первая реакция заключалась в том, чтобы относиться к этому как к Google Cloud, Heroku или другим предложениям PAAS, основанным на «проектах». Мой первоначальный подход был…
- Создайте кластеры xyz-development, xyz-staging и xyz-production с соответствующими конфигурациями.
- Создайте конкретного пользователя среды, например пользователя `xyz-develop`, который будет иметь эксклюзивный доступ к базе данных xyz-develop.
- Сконфигурируйте пользователя с привилегиями readWrite и dbAdmin для кластера, чтобы дополнительные изменения, такие как большее количество сегментов, автоматически входили в права управления доступом пользователя.
Однако это не рекомендуемый и не функциональный способ решения этой проблемы. MongoDB в Атласе не предоставляет разрешения на уровне кластера. Таким образом, пользователям могут быть предоставлены права либо на все базы данных, либо на определенные базы данных, что не очень удобно, это слишком детально.
Правильный путь
После того, как вышеперечисленное не удалось заставить работать, и поговорив с командой MongoDB Atlas, оказалось, что они предлагают другой подход. Они поощряют активное использование групп Атласа.
Доступ к группам можно получить после входа в MongoDB Atlas, посетив Настройки ›Мои группы. Предлагаемый подход состоит в том, чтобы думать об окружающей среде на уровне группы, а не на уровне пользователя. Есть несколько минусов, но множество преимуществ, о которых я расскажу ниже. Имея это в виду, правильный поток для создания кластеров на основе среды и пользователей с надлежащим контролем доступа ...
- Создайте группы xyz-develop, xyz-staging и xyz-production.
- Создайте кластеры xyz-development, xyz-staging и xyz-production в соответствующих группах. Например, кластер xyz-develop будет исключительно внутри группы xyz-develop.
- Затем создайте пользователя в каждой соответствующей группе с правами dbAdmin и readWrite для всех баз данных.
- Повторите эти действия для каждой среды, сохраните пароли для каждого пользователя и вуаля, у вас есть сегментированный контроль доступа для каждой среды.
Хотя у самой команды MongoDB Atlas нет официально задокументированного метода, это было подтверждено их службой поддержки в качестве предлагаемого и поддерживаемого подхода к управлению доступом для каждой среды.
