05.04.2022 07:35
CloudMaker 0 1800 Источник

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

Мы высоко ценим автоматизацию процессов и унификацию инфраструктуры, проект призван объединить все используемые технологии в одном централизованном и самодокументируемом месте, с безопасным, прозрачным и логируемым доступом к любому серверу и инструменту сразу через несколько пользовательских интерфейсов (CLI, Web, API, Telegram, Discord, Mattermost, Slack).

Проект разработан в соответствии с принципами и правилами "Unix" философии, основой системы являются shell утилиты и дополнительные пользовательские интерфейсы (Web, API, Telegram, Discord, Mattermost, Slack) на Python, каждая из утилит подключает базовую микро библиотеку и выполняет определенную задачу, вместе они составляют логическое ядро.

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

Каждый модуль может содержать: утилиты, подключаемые элементы дополнительных пользовательских интерфейсов, readme файл, auditor файл (если для модуля требуется отдельный watchdog) и скрипты инициализации модуля.

Все компоненты модулей автоматически парсятся соответствующими компонентами ядра и подключаются к системе, также парсится Readme файл и help вывод имеющихся утилит по блокам (описание, аргументы, примеры использования) для последующей автоматической генерации документации проекта.

Дополнительные пользовательские интерфейсы являются универсальным средством авторизации для использования инструментов ядра и модулей.

При инициализации системы в каждом дополнительном интерфейсе генерируются методы валидации для возможности использования всех обнаруженных скриптов.
Любой имеющийся или кастомный скрипт помимо CLI может быть использован в браузере через консоль веб интерфейса, по API и через чат бота в поддерживаемых мессенджерах.

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

При доступе к системе в первую очередь используется аутентификация по PAM и доверенным спискам IP адресов на уровне ОС и веб сервера, авторизация доступа к инструменту использует несколько факторов валидации на уровне приложения/веб сервера и/или на уровне системы (sudoers файл генерируемый на основе матрицы доступов), любой имеющийся модуль или инструмент может быть расшарен для использования определенному пользователю через любой доступный интерфейс исключая при этом прямой доступ пользователей к коду скриптов, контенту модулей, а также ко всей директории системы.

Основу безопасности проекта обеспечивает acсess модуль. Он предоставляет пользователям возможность, генерировать персональные VPN ключи и обновлять IP адресы из которых составляются доверенные списки для инстансов в соответствии режимом политики сетевой безопасности. Также он отвечает за централизованное управление SSH ключами и деплой на удаленные серверы доверенных списков и правил фаервола(iptables) для закрытия чувствительных портов с возможностью тонкой настройки для отдельных инстансов или групп.

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

Примеры использования

Для упрощенного понимания и визуализации концепции проекта ниже представлены несколько из множество возможных примеров использования.

В скринкастах использована ОС Android исключительно для минималистичного представления работы системы через несколько программных интерфейсов и демонстрации переключения между ними, разумеется при работе с системой в основном используются десктопные ОС, также в примерах используется следующее ПО:

  • Termius в качестве SSH/SFTP клиента;

  • Chromium бразуер при использовании веб интерфейса;

  • Telegram, в качестве клиента одного из нескольких чат бот интерфейсов.

Централизованная система доступа и SSH гейт

Основой проекта является централизованная система доступа по SSH на основе PAM.

  • Все CLD пользователи взаимодействуют с системой в соответствии в внутренней матрицей доступов и имеют настраиваемые разрешения, им могут быть назначены персональные ID аккаунтов мессенджеров, а также автоматически выдается API токен.

  • Каждый пользователь авторизуется на сервере через соответствующую PAM учетную запись.

  • Доступ к разрешенным серверам обеспечивается через единый приватный ключ или пароль учетной записи инстанса.

  • Список разрешенных серверов для подключения пользователь определяется как указанием отдельного инстанса, так и расшариванием группы инстансов пользователю.

  • SSH ключ и пароли с помощью которые происходит авторизация на удаленных инстансах не доступны пользователю.

На анимации продемонстрировано как пользователь пытается получить доступ к инстансам, затем admin используя панель управления расшаривает один из инстансов для пользователя, а затем группу инстансов, также демонстрируется работа интерактивного SSH гейта

Защита всех серверов на любом хостинге

Доступ на все серверы защищен по доверенным спискам IP адресов.

  • Доступ к CLD серверу (как и ко всем подключенным к системе инстансам) ограничивается по доверенным спискам IP адресов.

  • Модуль access предоставляет возможность обновлять пользовательские доверенные адреса через мессенджеры (Telegram, Discord, Mattermost, Slack).

  • Пользователи могут сгенерировать персональные VPN ключи для доступа к CLD серверу и инстансам.

  • Доверенные списки обновляются на инстансах по крону, также обновление инициируется службой аудита по триггеру при изменении в доверенных списках или матрице доступа.

  • Списки разрешенных портов на серверах имеют возможность настройки, отдельные списки портов могут быть настроены как для отдельного инстанса так и для группы инстансов.

  • Политика сетевой безопасности для всех инстансов представлена в трех режимах -general, private и paranoid:

    • general - Все доверенные IP адресы CLD пользователей имеют сетевой доступ к защищенным портам инстансов - значение по умолчанию;

    • private - Политика сетевых разрешений для каждого инстанса в соответствии с картой доступов;

    • paranoid - Как "private", но все внешние подключения к CLD серверу закрыты даже для /api/all/* эндпоинтов в API системы, обновление доверенных IP адресов возможно только через VPN подключение или через уже установленное SSH подключение через CLI и через мессенджеры с указанием IP адреса вручную, т.к. функционал авто определения IP адреса через API в этом политике безопасности недоступен.

На анимации продемонстрировано как пользователь пытается подключиться к серверу, соединение сбрасывается пока пользователь не обновит свой доверенный IP адрес через бота в мессенджере используя ссылку с одноразовым токеном.

Интеграция с CloudFlare

Управление DNS зонами в нескольких аккаунтах.

  • Просмотр, редактирование и удаление DNS записей для любого домена через любой CLD интерфейс.

  • Возможность управлять любыми настройками CloudFlare для домена, а также сбрасывать CDN кэш.

  • Резервное копирование DNS зон во всех подключенных аккаунтах.

  • Функционал переключения множества доменов с одного IP адреса на другой с авто определением какие домены направлены на текущих IP адрес.

  • Поддержка инструментов просмотра гео данных адреса и whois.

  • Инструмента для массового выпуска wildcard сертификатов всех подключенных доменов к CloudFlare через DNS валидацию.

На анимации продемонстрировано как пользователь используя различные интерфейсы запрашивает значение DNS записи для домена в терминале, удаляет запись через бота в мессенджере и задает другой адрес для DNS записи через терминал.

Единая точка доступа SFTP

Пользователи могут получить логируемый файловый доступ любого инстанса.

  • Все файловые операции логируются по пути /var/cld/log/session/$user/$date/$instance_sftp_$time.gz.

  • 2 инструмента для монтирования файловой системы инстанса: cld-mount (интерактив), cldxmount(монтируется первый инстанс после фильтрации).

  • Пользовательские функции монтирования позволяют получить файловый доступ к любому типу серверов и контейнеров по любому протоколу.

  • Данный функционал позволяет копировать, синхронизировать и перемещать данные с сервера на сервер без прямого доступа между ними.

На анимации продемонстрировано как пользователь монтирует файловую систему удаленного сервера, проверяет статус монтирования в командной строке и проверяет доступ к файлам через STTP клиент подключенный к CLD серверу.

Парсинг групп инстансов

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

  • Тип группы "parsing" имеет пользовательский скрипт, он будет постоянно непрерывно синхронизировать списки инстансов в группу, вы всегда будете иметь доступ ко всем вашим серверам где бы они не находились.

  • Парсинг любых облачных провайдеров может быть реализован - скрипт парсинга может использовать API или внешние инструменты CLI установленные на CLD сервер, скрипты парсинга ничем не ограничены.

  • Встроенный парсинг групп: AWS cloud, Google cloud, Hetzner cloud, DigitalOcean, Azure cloud, Scaleway cloud, OVH cloud, Proxmox LXC, Docker containers, Kubernetes containers.

  • Система парсинг инстансов сочетается с различными инструментами автоматизации и безопасности, такими как непрерывное обновление доверенных IP адресов и SSH ключей.

На анимации продемонстрировано как пользователь проверяет список группы инстансов Hetzner cloud, затем меняет тип группы на "parsing" с соответствующим скриптом в панели администрирования CLD, создает инстанс в Hetzner cloud, как только сервер создан он сразу доступен в CLD.

Управление KVM виртуальными машинами

Создание, управление и миграция KVM виртуальных машин на PVE гипервизорах:

  • Интерактивное создание KVM виртуальных машин с выбором операционной системы, количества ядер процессора, объем ОЗУ, дискового пространства и сетевые настройки.

  • Единая точка управления KVM виртуальными машинами на всех гипервизорах (не имеет значения находятся ли они в кластере, в различных ДЦ и т.д.), доступные команды: start, stop, pause, resume и delete.

  • Скрипт деплоя PVE гипервизора с сетевыми настройками и конфигурацией стореджей.

  • Интерактивная миграция виртуальных машин между гипервизорами с использованием pve-zsync, предварительная поэтапная синхронизация перед переключением (автоматическая миграция IP адресов поддерживается для некоторых хостинг-провайдеров).

  • Парсинг доступных бэкапов для всех гипервизоров с прозрачным ежедневным отчетом в мессенджере.

На анимации продемонстрировано интерактивное создание KVM виртуальной машины через веб интерфейс модуля, после создания пользователь проверяет статус ВМ, получает SSH доступ через веб интерфейс и проверяет настройки и ресурсы указанные в процессе создания.

Пользовательские модули для любого функционала

Поддержка пользовательских модулей для расширения возможностей системы.

  • Интерактивное создание по шаблону модуля, пользовательский API метод, веб страница редактирования модуля и пример shell утилиты.

  • Модули расположены в директории /var/cld/modules/, модуль может содержать:

    • утилиты bin/cld-*;

    • Пользовательские методы интерфейсов ./{api,bot,web}.py;

    • Пользовательские файлы web интерфейса web/${module}.html, web/content/somefile.{css,js,svg} и т.д.;

    • Файл документации ./README.md;

    • Файл аудитор демона ./auditor;

    • Данные пользовательских модулей рекомендуется располагать в директории ./data;

  • Пользовательские методы интерфейсов модуля могут быть связаны с друг другом, для примера как это реализовано в встроенном access модуле.

  • Утилиты модуля могут быть написаны на любом языке программирования, включая компилируемые.

  • Код CLD интерфейсов для стандартного запуска утилит модуля генерируется автоматически во время запуска systemd служб CLD интерфейсов, а также код пользовательских методов парсинг и загружается в интерфейсы автоматически.

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

Резервное копирование на любой случай

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

  • Независимые методы резервного копирования для каждого инстанса.

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

  • Резервное копирование выполняется на удаленном сервере бэкапа.

  • Процесс резервного копирования оптимизирован для многопоточного копирования данных.

  • Встроенные методы резервного копирования:

    • ETC: Бэкап файлов конфигурации расположенные в /etc/ или другой директории;

    • Files: Бэкап файлов и директорий целиком позволяет быстро и удобно настраивать резервное копирование для необходимых элементов;

    • MongoDB: Настраиваемый бэкап баз данных MongoDB любого размера;

    • ClickHouse: Резервное копирование баз данных ClickHouse;

    • MySQL: Бэкап баз данных MySQL, с возможность выполнять локально на сервере базы данных или удаленно на бэкап сервере;

    • PostgreSQL: Бэкап баз данных PostgreSQL.

  • Пользователи CLD могут создавать их собственные методы бэкапов, на примере расположенных в /var/cld/modules/backup/methods.

На анимации продемонстрировано создание конфигурации бэкап методов для пары инстансов и генерация отчета в мессенджере.

Интерфейсы:

CLI

Основной интерфейс для работы CLD системы, многие основные скрипты работающие в интерактивном режиме разработаны для работы через CLI.

  • CLI запуск валидируется пользовательскими алиасами в ~/.bashrc;

  • Каждый алиас содержит запуск через sudo;

  • Список алиаслов и доступных CLD утилит в /etc/sudoers - генерируется утилитой cld-initpasswd в соответствии с матрицей доступов /var/cld/creds/passwd;

  • Если модуль расшарен для пользователя, все утилиты модуля добавляются в алиасы и становятся через sudo для этого пользователя.

API

Интерфейс для доступа к не интерактивным инструментам через API.

  • Код интерфейса написан на Python, используя Flask фреймворк;

  • Пример запроса: https://cld.example.com/api/${TOOL}?token=${USER_TOKEN}&args=${ARGUMENTS};

  • Токены пользователей хранятся в файле /var/cld/creds/passwd, персональный токен пользователя доступен через веб интерфейс в разделе профиль;

  • Во время запроса, утилита выполняется с предоставленными аргументами через GET аргумент args;

  • Необходимые аргументы:

    • token - API токен пользователя CLD.

  • Доступные GET аргументы:

    • args - аргументы командной строки будут переданы к CLD утилите как есть с учетом regex фильтрации;

    • output - "plain" или "html" - если задано "html" значение, цветной вывод консоли будет преобразован в html - значение по умолчанию: "plain";

    • mode - пример ?token=${USER_TOKEN}&args=${ARGUMENTS}&mode=track

      • stream - вывод будет передаваться построчно в режиме реального времени, есть возможность наблюдать за прогрессом выполнения, но код ответа будет всегда 200 - это значение по умолчанию;

      • track - вывод будет задан как plain/text и будет доступен только после завершения выполнения CLD утилиты, код ответа зависит от кода возврата скрипта:

        • если CLD утилита вернет код 0 (без ошибок) - код ответа API будет 200;

        • в ином случаи код будет 500 - может быть полезно для отслеживания статуса в CI/CD системах.

  • Доступны пользовательские API эндпоинты и функции;

  • Во время запуска API интерфейса (systemd служба cld-api) производятся следующие операции:

    • Поиск всех доступных утилит и генерация кода для каждой утилиты с соответствующим эндпоинтом (часть "cld-" обрезается в эндпоинте);

    • Поиск api.py файлов в корне каждого модуля, этот код выполняется как есть как часть всего API интерфейса.

  • Пример использования пользовательских эндпоинтов и функций можно посмотреть в access модуле, файл /var/cld/modules/access/api.py;

  • Локейшен /api/:

    • Доступны только для доверенных списков адресов;

    • Автоматически генерируемые эндпоинты для утилит создаются в контексте этого локейшена;

    • Доверенными списками адресов для nginx генерируются в файл /etc/nginx/accesslist.

  • Локейшен /api/all/:

    • Доступен для всех IP адресов, исключая запрещенный список и если не используется сетевая политика безопасности "paranoid";

    • Может быть доступен только для пользовательских эндпоинтов;

    • Количество запросов для локейшена /api/all/ ограничено до 60 запросов в минуту.

Bot

Telegram/Discord/Mattermost/Slack чат бот интерфейсы для выполнения утилит вне интерактивного режима:

  • Код интерфейса каждого чат бота написан на Python;

  • При отправке команды в чат или боту напрямую, утилита выполняется с переданными аргументами прошедшими regex фильтрацию;

  • Пример выполнения команды: /command arg1 arg2 (первый символ может отличаться, или не требоваться, как к примеру в Mattermost и Slack);

  • Доступ валидируется на уровне приложения на основе ID пользователя, заданного в файле /var/cld/creds/passwd;

  • Вывод от выполнения утилиты отображается в режиме реального времени через обновление ответного сообщения от бота;

  • При запуске бот интерфейса (systemd служб cld-tgbot/cld-dcbot/cld-mmbot/cld-slbot) производятся следующие операции:

    • Поиск всех доступных утилит и генерация кода команды для каждого инструмента (по аналогии с API интерфейсом, "cld-" обрезается из имени каждого инструмента);

    • Поиск bot.py/mmbot.py/dcbot.py/slbot.py файлов в корне каждого модуля, этот код выполняется как часть данного чат бот интерфейса.

  • Доступны пользовательские команды и функции;

  • Пример использования пользовательских команд и функций можно посмотреть в access модуле, файл /var/cld/modules/access/bot.py;

  • Для расшаривания модуля или утилиты для чат группы необходимо создать отдельного пользователя в CLD и назначить ему ID чат группы мессенджера, ID можно запросить у бота в любом мессенджере командой /getid.

Web

Вспомогательный интерфейс для работы с системой

  • Код интерфейса написан на Python используя Flask фреймворк и различные модули, например, SocketIO.

  • Интерфейс предоставляет различный функционал для управления системой.

  • Имеет доступ ко всем CLI элементам включая интерактивные через веб терминал в браузере.

    • Браузерная веб консоль реализована с использование XtermJS и SocketIO.

  • Позволяет работать с системой через веб консоль вообще без использования SSH клиента.

  • Во время запуска веб интерфейса (systemd служба cld-web) производятся следующие операции:

    • Поиск всех доступных утилит и генерация кода для каждой утилиты с соответствующим эндпоинтом (часть "cld-" обрезается в эндпоинте);

    • Поиск web.py файлов в корне каждого модуля, этот код выполняется как часть данного чат бот интерфейса;

      • Если web.py найден в корне модуля, создается симлинк к /var/cld/web/modules/${MODULE}/web директории от /var/cld/web/modules/${MODULE} для доступа к файлам статики модуля снаружи Flask директории приложения.

  • Каждый отображаемый блок модуля на главной странице веб интерфейса генерируется если web.py файл обнаружен и направляется на индекс эндпоинт указанный в web.py коде модуля;

    • Имя и описание модулей указывается в свойствах webmodule объекта заданном в web.py файле каждого модуля, пример можно посмотреть в файле веб интерфейса модуля документации - /var/cld/modules/doc/web.py;

    • Логотип модуля будет отображен если находится по пути /var/cld/web/modules/${MODULE}/content/logo.svg, в обратном случаи будет отображен стандартный логотип.

  • В качестве текстового редактора в веб интерфейсе используется Ace Cloud9 Editor.

Модульный концепт

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

  • access - Контроль доступа к серверам по доверенным спискам и централизованное управление SSH ключами;

  • backup - Резервное копирование файлов, баз данных и конфигураций CLD инстансов;

  • ansible - Запуск плейбуков из стореджа на CLD инстансах доступных пользователю;

  • kubernetes - Управление несколькими кластерами, хранилище helm чартов и деплой доверенных списков адресов в ingress;

  • cm - создание/управление/миграция виртуальных машин на базе Proxmox Virtual Environment;

  • dns - Интеграция с CloudFlare для массового управления DNS записями сразу в нескольких аккаунтах;

  • doc - Ядро системы самодокументации - генерация документации на основе парсинга Readme.md файлов и help вывода всех имеющихся утилит и модулей.

Система спроектирована таким образом, чтобы добавление новых функциональных модулей для любых целей происходило максимально быстро за счет унификации и автоматической генерации кода для API и чат ботов мессенджеров, некоторые из CLD систем содержат до сотни пользовательских модулей предоставляющие самый разнообразный функционал и автоматизацию включая комплексные CI/CD решения.
Доступ к модулям через CLI, чат боты, API и через веб интерфейс отдельно настраивается для каждого пользователя.

Установка

CLD необходимо устанавливать на чистую операционную систему, рекомендуется использовать Centos 8 Stream, т.к. работа с этим дистрибутивом наиболее хорошо протестирована в продакшене.

Рекомендованные системные требования:

  • Virtualization: KVM/Bare metal;

  • Поддерживаемые ОС: Centos 7/8, Debian 9/10;

  • Процессор: 1 ядро;

    • 1 дополнительное ядро на каждые 500 инстансов.

  • ОЗУ: 2 Гб;

    • 1 Гб дополнительной ОЗУ на каждые 500 инстансов.

  • Дисковое пространство: 20 Гб;

    • 10 Гб дополнительно на каждые 500 инстансов.

  • Прямой публичный ip адрес.

Данные необходимые для функционирования интерфейсов и модулей

Перед установкой следует подготовить следующее:

  • Для интерфейсов (чтобы использовать любой доступный пользовательский интерфейс):

  • Для модулей (пример информации которая может быть затребована init скриптами модулей):

    • cm - API реквизиты доступа для поддерживаемых bare metal хостинг провайдеров OVH/Online.net/Hetzner;

    • dns - Реквизиты доступа к CloudFlare аккаунтам (login, API key, user ID);

    • zabbix - Реквизиты доступа к Zabbix server (login, password, domain, url for Zabbix API);

    • Информация по данным остальных модулей доступна на странице документации в разделе каждого модуля ( https://classicdevops.com/documentation/ ).

Быстрый старт

Установка может быть произведена следующей командой:

bash -x <(wget -qO- "https://raw.githubusercontent.com/classicdevops/cld/master/setup/install_cld.sh")

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

После завершения установки в консоль будут выведены пароль для пользователя admin и ссылка на веб интерфейс.

Политика поддержки

Пожалуйста не задавайте вопросы в github issues. Такой формат не очень хорошо подходит для ведения FAQ.

Если у Вас есть вопрос, пожалуйста создайте его на ServerFault.

Укажите к вопросу тэги cld и classicdevops (оба сразу).

Мы непрерывно парсим список вопросов по этим тэгам, получаем уведомления и постараемся ответить так быстро насколько это возможно. Делайте ваш пользовательский опыт доступным для всех!

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

Заключение

Хотелось бы отметить, что CLD берёт на себя решение сразу несколько действительно важных задач, от которых напрямую зависит безопасность и эффективность инфраструктуры компании. Комплексный подход позволяет организовать работу по направлениям которые тесно связаны и нуждаются в стандартизированной реализации. Эффективное обеспечение безопасности инфраструктуры предполагает наличие удобных и надежных инструментов защиты, прозрачности процессов, управления доступом и логирования. Руководствуясь основными принципами информационной безопасности: CLD приемлет открытую архитектуру ИС, стойкость, контроль над всеми операциями и простоту использования.

Для Linux системного администратора или DevOps инженера CLD представляет единый набор технологий и инструментов, интеграция и последующее использование не вызовет особых сложностей, а с учетом уже разработанной подробной документации - позволит в короткие сроки начать использовать продукт.

Статус открытого программного обеспечения подразумевает возможность бесплатного использования CLD в своих целях любым пользователем.

Авторы статьи:
Александр Чендев
Александр Багринцев

Контакт: root@classicdevops.com

Ссылки:
Github
Документация
Сайт проекта

Комментарии (0)