Суверенитет облачной нативной платформы определяется не только местом выполнения рабочей нагрузки или хранения её данных. Согласно анализу, опубликованному CNCF 18 августа 2026 года и написанному Chamod Perera, послом CNCF, и Suvin Kodituwakku, старшим инженером-программистом в WSO2, доказательство суверенитета также зависит от места хранения состояния управления, маршрутов журналов и метаданных, организаций, способных получить доступ к ключам и учётным данным, а также способности команды продолжать работу, если сервис поставщика станет недоступен.
В материале предлагается рассматривать суверенитет как свойство топологии платформы, а не просто как выбор региона в списке настроек. В качестве проверяемого примера такого подхода используется OpenChoreo — внутренняя платформа для разработчиков с открытым исходным кодом и проект CNCF на стадии Sandbox, — при этом подчёркивается, что архитектурные принципы не ограничиваются этой платформой.
Четыре вопроса, выходящие за рамки расположения серверов
В материале отмечается, что в условиях таких нормативных рамок, как EU Data Act, NIS-2, DORA и UK Data Use and Access Act, перед платформенными командами стоят практические вопросы, выходящие за рамки определения географического региона. Первый вопрос: под какой юридической юрисдикцией работает каждый компонент, способный соприкасаться с данными арендатора, включая уровень управления и журналы? Второй: может ли команда выполнять рабочие нагрузки, пересобирать их и переносить их, если сервис, размещённый у поставщика, прекратит работу?
Два других вопроса связаны с возможностью доступа сторон за пределами границы к ключам, состоянию кластеров или административным учётным данным, а также с тем, потребует ли смена поставщика, оборудования или страны переписывания рабочей нагрузки. Анализ делает вывод, что эти вопросы в первую очередь сосредоточены на том, где находятся управление и состояние и кто обладает возможностью получить к ним доступ.
Как работает многоуровневая архитектура?
OpenChoreo разделяет платформу на независимые кластеры, каждый из которых имеет собственный жизненный цикл, границы безопасности и поведение при масштабировании:
- Уровень управления: хранит желаемое состояние через декларативные API и запускает модули согласования, но не выполняет рабочие нагрузки арендаторов.
- Уровни данных: совместимые кластеры Kubernetes, фактически выполняющие рабочие нагрузки; у каждого есть независимые API-сервер и состояние.
- Уровни мониторинга: собирают и обслуживают журналы, метрики и трассировки.
- Уровни рабочих процессов: выполняют операции CI и GitOps.
- Уровень взаимодействия: предоставляет портал разработчика, CLI, API и MCP.
Ключевым элементом является модель соединений. Уровни данных, мониторинга и рабочих процессов устанавливают исходящие соединения с взаимной аутентификацией через mTLS с шлюзом уровня управления, тогда как уровень управления не инициирует соединения с ними. Поэтому API-серверы кластеров, в которых размещены регулируемые рабочие нагрузки, не оказываются открытыми в интернете. Кроме того, уровень управления хранит желаемое состояние, а не полное рабочее состояние арендатора; поэтому уровень данных может продолжать обслуживать запросы даже при потере связи с уровнем управления.
Что это практически меняет для платформенных команд?
Каждый уровень данных можно связать с конкретной юридической юрисдикцией, благодаря чему модель «одна юрисдикция — один уровень данных» становится проверяемой и пригодной для аудита. Каждый уровень данных также отправляет свои эксплуатационные данные на региональный уровень мониторинга, вместо того чтобы передавать журналы и трассировки через уровень управления. Благодаря этому рабочие нагрузки арендаторов и их показатели остаются в заданных региональных границах.
Возможность продолжать работу независимо от поставщика обеспечивается тем, что каждый уровень данных представляет собой полноценный совместимый кластер Kubernetes, а не закрытую управляемую конечную точку. В анализе упоминается использование компонентов с открытым исходным кодом из экосистемы CNCF и облачной нативной экосистемы, таких как Argo Workflows, Cloud Native Buildpacks, OpenSearch, Prometheus, OpenTelemetry, Flux, cert-manager и Cilium. Модульная архитектура позволяет заменить компонент или подключить существующую систему мониторинга с тем же интерфейсом запросов.
Защита секретов и ключей передаётся совместимому с External Secrets Operator хранилищу или выбранному оператором хранилищу, вместо навязывания владения ключами по умолчанию. Также можно применять детализированные разрешения на уровне пространств имён, проектов и компонентов, связывая группы с любым поставщиком идентификации OAuth2/OIDC — независимо от того, является ли вызывающая сторона разработчиком, CLI-инструментом или агентом искусственного интеллекта.
Интеграция виртуальных кластеров с уровнями платформы
Эта модель не отменяет шаблон кластера арендатора, а дополняет его. Виртуальный кластер предоставляет каждому арендатору виртуальный уровень управления, собственный API-сервер и хранилище внутри общего кластера-хоста, изолируя состояние управления между арендаторами с меньшими затратами, чем отдельный кластер для каждого арендатора. Однако сам по себе он не определяет юрисдикцию, в которой должен размещаться арендатор, место отправки журналов или то, кто имеет право переводить рабочую нагрузку между двумя средами или регионами.
Здесь уровень платформы добавляет средства управления распределением и эксплуатацией. Ресурс DataPlane может содержать метку юридической юрисдикции, связывать ресурс observabilityPlaneRef с региональным уровнем мониторинга, а маршруты продвижения определяют среды, между которыми может перемещаться рабочая нагрузка. Портал разработчика также предоставляет готовые пути, уменьшая необходимость предоставлять пользователям прямой доступ к чувствительным кластерам.
Однако у этой комбинации есть чёткое ограничение: арендаторы, находящиеся на одном хосте, совместно используют узел и ядро операционной системы. Если модель угроз требует аппаратной изоляции каждого арендатора, виртуального кластера будет недостаточно и потребуется отдельный физический уровень данных.
Суверенитет как декларативная конфигурация, пригодная для аудита
В анализе предлагается представлять топологию через декларативные ресурсы Kubernetes и хранить их в Git: какой регион использует какой уровень данных, какой пункт назначения получает данные мониторинга и какие маршруты продвижения разрешены. Тогда создание новой юрисдикции становится подлежащим проверке запросом на слияние (pull request), а ответ на вопрос о том, почему данные арендатора находятся в определённом регионе, основывается на журнале изменений, а не на снимке экрана панели управления.
Тем не менее многоуровневая архитектура не меняет юридическую юрисдикцию организации, эксплуатирующей инфраструктуру, и не устраняет её подверженность законодательным системам, которым она подчиняется. Она также очерчивает границы, но сама по себе не обеспечивает соблюдение политик внутри них: аттестация цепочки поставок, SBOM, аудит и идентификация рабочих нагрузок с помощью таких инструментов, как SPIFFE/SPIRE, остаются отдельными средствами контроля, требующими интеграции.
Последним ограничением становится эксплуатационная стоимость: каждому дополнительному кластеру необходимы мониторинг, обновление и резервное копирование. Поэтому такая архитектура оправдана, когда установленные границы имеют реальный юридический или защитный вес, и может оказаться избыточной в средах, где это не требуется. В итоге сочетание кластеров арендаторов для изоляции ресурсов, многоуровневой архитектуры для определения того, что может пересекать границы, и декларативных конфигураций, пригодных для управления версиями, превращает суверенитет из договорного обещания в свойство, которым можно управлять и которое можно проверять.