Оценка Opfield

На этой странице собраны вопросы, которые покупатели и их специалисты по безопасности обычно задают до выбора Opfield. Каждый ответ короткий и ведёт на страницу с подробным описанием поведения. Ответы относятся к текущему выпуску; возможности из дорожной карты отмечены в матрице возможностей.

Можно ли разместить Opfield самостоятельно на платном тарифе?

Да. Любой тариф — Community, Personal, Business и Enterprise — можно установить и эксплуатировать на собственной инфраструктуре. Платный тариф — это лицензионный ключ, применённый к самостоятельно размещённой установке; он не переносит плоскость управления в другое место. Вариант управляемого облака, в котором плоскость управления Opfield эксплуатирует Square Labs, предоставляется отдельно по запросу. Это альтернатива, а не обязательное условие какого-либо тарифа.

Для Community лицензионный ключ не нужен; этот тариф допускает до 25 управляемых нод, 3 пользователей и 1 пользовательскую группу разрешений. Каждый ключ Personal, Business или Enterprise относится к одной активной установке Opfield и снимает эти квоты. Платные функции поставляются как подписанное коммерческое ядро, которое установка загружает и проверяет; см. Коммерческое ядро. См. Установка Opfield или ручную установку, если ваша проверка безопасности не разрешает передавать загруженный установщик прямо в командную оболочку.

Где хранятся наши секреты и ключи в самостоятельно размещённой установке?

Внутри установки. Opfield — плоскость управления, которую эксплуатируете вы, поэтому учётные данные, с помощью которых он управляет инфраструктурой, остаются в вашем окружении:

• Сохранённые учётные данные — секреты и переменные среды Docker, учётные данные реестров, токены DNS и хостинг-провайдеров, ключи SSH, секреты OIDC и SMTP, учётные данные баз данных, ключи провайдеров AI, закрытые ключи центров сертификации и ACME, а также сам лицензионный ключ — зашифрованы конвертным шифрованием AES-256-GCM и хранятся в собственной базе PostgreSQL установки.
• Мастер-ключ, который их защищает (PKI_MASTER_KEY), создаётся на вашем хосте при установке и хранится в файле .env установки, а не в базе данных. Он не покидает хост, если вы сами его не скопируете.
• Закрытый ключ TLS самого Opfield остаётся на хосте Opfield. Каждая управляемая нода хранит закрытый ключ своего демона локально, а ноды хранилища хранят ключи TLS баз в хранилище демона.

Защищайте хост Opfield как привилегированную систему и храните резервную копию мастер-ключа отдельно от резервных копий базы данных: без мастер-ключа резервную копию базы нельзя расшифровать. См. Модель безопасности и Обновления, резервные копии и восстановление.

Что Opfield передаёт службе лицензирования?

Только метаданные установки. Opfield обращается к https://license.thesqlabs.com, чтобы зарегистрировать установку, отправлять контрольный сигнал — каждые 15 минут с платным ключом и каждые 30 минут на Community, — активировать или деактивировать ключ, авторизовать целевой выпуск перед обновлением и, для лицензированной установки, загружать подписанное коммерческое ядро.

Запросы содержат идентификатор установки, имя установки (имя хоста из настроенного публичного URL или имя сервера), версию Opfield, версию схемы Entitlements и токен установки. Одноразовый код регистрации передаётся при регистрации, платный ключ — при его активации, а целевая версия, идентификатор выпуска и путь к файлу — при обновлении. Конфигурация инфраструктуры, содержимое ресурсов, секреты, журналы, число пользователей или ресурсов, запросы к моделям и их ответы не передаются.

Проверки прав и Entitlements используют состояние лицензии, сохранённое в вашей установке, поэтому отдельные операции не ждут ответа службы лицензирования. Остальные исходящие соединения, например проверка выпусков, перечислены в разделе Что покидает самостоятельно размещённую установку.

Что будет, если лицензия истечёт или служба лицензирования станет недоступна?

Работающая инфраструктура продолжит работать. Ни истечение ключа, ни недоступность службы лицензирования не останавливают и не удаляют контейнеры, Deployments, Compose Project, Routes, сертификаты, движки управляемых баз данных и опубликованные развёртывания Pages.

• Истечение ключа. После даты окончания платный тариф остаётся полностью активным в течение льготного периода: 24 часа на Personal, 3 дня на Business и 7 дней на Enterprise. Во время льготного периода Dashboard показывает предупреждение. После него рабочие нагрузки, контур данных и данные продолжают работать; резервное копирование по расписанию, восстановление в существующие базы данных, просмотр, журналы, мониторинг, раскрытие учётных данных и удаление существующих платных ресурсов остаются доступны. Создание платных ресурсов и изменение их конфигурации блокируются, а пересылка в SIEM и внешний доступ к реестру приостанавливаются до продления.
• Служба лицензирования недоступна. Ранее подтверждённая платная установка сохраняет тариф в течение 100 дней после времени выдачи последнего подписанного состояния лицензии со статусом Licensed with warning. Этот период не продлевает известный срок окончания ключа. Через 100 дней поведение совпадает с обычным истечением. Установки Community продолжают работать, пока служба недоступна, а установка Community без ключа и обновляется без неё. Для активации платного ключа и для обновления установки, у которой есть или был платный тариф, служба должна быть доступна; неудачное обновление оставляет работать текущую версию. См. Условия обновления в 2.11.
• Объекты сверх лимитов Community. Лимиты Community проверяются только при создании управляемой ноды, пользователя или пользовательской группы разрешений. Существующие ноды, пользователи и группы сверх лимита продолжают работать и никогда не удаляются.
• Понижение и продление. При переходе на более низкий платный тариф более высокий тариф сохраняется на время своего льготного периода. Продление ключа восстанавливает все операции без пересоздания ресурсов. Установки, у которых был платный тариф, продолжают получать обновления с коммерческим ядром, поэтому существующие платные ресурсы продолжают работать после обновления.

Для отзыва, переноса ключа на другую установку, деактивации или недействительного ключа льготного периода нет: правила после льготного периода применяются сразу, а работающие рабочие нагрузки продолжают работать. Состояния лицензии от службы подписываются и проверяются Opfield, поэтому поддельный или повторённый ответ не может изменить тариф. См. Понижение и истечение.

Может ли команда перезапускать контейнеры и читать журналы без принятия проекта под управление?

Да — для автономных контейнеров; для внешних проектов Compose — только чтение.

• Автономные контейнеры, в том числе запущенные командой docker run вне Opfield, отображаются на своей ноде Docker без шага принятия под управление. Группе можно выдать docker:containers:manage на один контейнер, чтобы запускать, останавливать, перезапускать и принудительно завершать его и читать его журналы, не получая доступа к другим контейнерам или сведениям о хосте. manage также разрешает пересоздание; права только на перезапуск нет.
• Внешние проекты Compose обнаруживаются по меткам Docker Compose. Право docker:compose:view на один проект показывает его службы, состояние, мониторинг и объединённые журналы на любом тарифе. Перезапустить внешний проект или отдельный его контейнер нельзя: действия жизненного цикла требуют принятия проекта под управление, а для этого нужен тариф Personal или выше. После принятия docker:compose:manage на этот проект позволяет запускать, останавливать и перезапускать весь проект.

Права можно выдать на один ресурс, одну ноду или папку Docker. Точные области прав и поведение идентичностей ресурсов при пересоздании контейнеров вне Opfield описаны в разделе Операции без принятия под управление.

Как передать Opfield существующий проект Docker Compose?

Примите обнаруженный проект под управление. Это явная передача ответственности, и для неё нужен тариф Personal или выше. Вы вставляете полный Compose-файл — Opfield не читает его с хоста, — а Opfield проверяет его, сохраняет как первую неизменяемую ревизию и применяет под тем же именем проекта Compose.

• Именованные тома сохраняют имена. Opfield не переименовывает проект и его тома и не добавляет к ним префиксы, поэтому Docker Compose повторно использует существующие тома <project>_<volume> или тома с явным name: вместе с данными. Для сервисов с состоянием, например Temporal, не меняйте ключи томов и до первого применения сравните список томов с обнаруженным проектом.
• env_file не поддерживается. Объявляйте переменные в environment: и передавайте их значения как переменные Opfield и зашифрованные секреты проекта через подстановку ${NAME}.
• Привязки каталогов хоста отклоняются, включая относительные пути вроде ./config. Перенесите файлы конфигурации в образ или именованный том.
• Разовые задачи. Аналога docker compose run и хуков перед развёртыванием нет. Выполните команду миграции через консоль контейнера службы или оформите её как службу с restart: "no", завершения которой другие службы ждут через depends_on; завершившаяся разовая служба считается остановленной.
• Другие ограничения. Службы должны использовать готовые образы, если у проекта нет источника Git на Business или Enterprise, а ключи вроде container_name, privileged, cap_add, devices, network_mode и deploy отклоняются. Полный список — в разделе Поддерживаемая конфигурация Compose.
• Удаление. При удалении управляемого проекта удаляются принадлежащие ему тома. Сначала создайте резервную копию постоянных данных.

При первом применении контейнеры служб, скорее всего, будут пересозданы, поэтому отрепетируйте принятие на тестовой копии. Compose Project нельзя перенести на другую ноду миграцией, а его контейнеры нельзя экспортировать в архив GWCA. Для автономных контейнеров это возможно: миграция копирует данные томов и сохраняет их имена, а архивы GWCA никогда не содержат данных томов. См. Compose Projects и Миграции и архивы контейнеров.

Чем управляемые базы данных отличаются от внешних?

Opfield работает с PostgreSQL, Redis и ClickHouse в двух моделях:

• Управляемую базу данных Opfield создаёт и запускает как контейнер с хранилищем фиксированного размера на ноде хранилища. Opfield отвечает за её жизненный цикл, изменение размера, публикацию с TLS, журналы, расширения PostgreSQL и приватные привязки, которые передают параметры подключения рабочим нагрузкам.
• Внешнее подключение хранит зашифрованные параметры подключения к базе, которая работает в другом месте. Opfield проверяет подключение, отслеживает состояние и предоставляет Explorer и консоли, но не создаёт, не приостанавливает, не масштабирует, не привязывает и не удаляет такой движок.

В 2.11 обе модели требуют тарифа Personal или выше, и обе можно защитить резервным копированием баз данных по расписанию в подключённое хранилище.

Полное сравнение — в разделе Управляемые и внешние базы данных: сравнение.

Помогаете ли вы с миграцией?

Начните с пилотного внедрения — поэтапного обратимого плана оценки с явными контрольными точками, который подходит для любого тарифа. Business включает сопровождение внедрения и проверку конфигурации, а Enterprise — помощь с развёртыванием и миграцией; это преимущества тарифа, объём которых определяется коммерческим соглашением. Если нужна помощь с миграцией на другом тарифе или для конкретного проекта, свяжитесь с Square Labs через сайт Opfield.

Где посмотреть цены?

Актуальные цены тарифов опубликованы в разделе цен на сайте Opfield. Эта документация не устанавливает цены и не содержит ценовых обязательств; договорные и ценовые условия, включая условия Enterprise, определяются применимым коммерческим соглашением. Функции и лимиты тарифов перечислены на странице Планы и права по тарифу.

Что дальше

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