Cordium: запуск изолированных песочниц в Kubernetes без передачи секретов

Современная разработка все сильнее полагается на автономных помощников: ИИ-агенты пишут тесты, анализируют логи и запускают сборки, а команды разработчиков тестируют код в динамических средах. Но вместе с автономностью приходит серьезная головная боль для специалистов по безопасности. Стоит предоставить агенту или непроверенному скрипту доступ к терминалу внутри контейнера, как любая неосторожная команда вроде printenv или чтение истории команд рискует скомпрометировать чувствительные корпоративные токены, приватные SSH-ключи и пароли к базам данных.

Традиционный подход с монтированием секретов через Kubernetes Secrets или переменные окружения больше не выдерживает критики при запуске недетерминированного кода. Открытая платформа Cordium от компании Octelium предлагает принципиально иную архитектурную парадигму: концепцию полного отсутствия статических секретов внутри рабочей среды (secretless access).

Почему секреты внутри контейнера превратились в мину замедленного действия

Долгое время стандартом изоляции считалось простое создание отдельного пода в кластере. Разработчик или раннер CI получал контейнер, в который заботливо пробрасывали доступы: строку подключения к базе данных, сервисные токены облака и ключи API. Пока за клавиатурой сидел человек, риск случайной утечки контролировался регламентами. Однако автономные языковые модели склонны исследовать файловую систему, выводить отладочные дампы и следовать вредоносным инструкциям в случае атак типа Prompt Injection.

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

Аналогия здесь проста: передавая контейнеру статические токены, вы отдаете курьеру связку ключей от всех комнат офиса. Подход Cordium работает иначе — как стойка службы безопасности на входе: курьеру разрешают передать конкретную посылку в конкретное окно, проверяя его бейдж при каждом шаге, но связку ключей в руки никогда не дают.

Архитектура нулевого доверия: как работает связка с Octelium

В основе платформы лежит модель Zero Trust Network Access (ZTNA). Cordium управляет жизненным циклом изолированных пространств в Kubernetes через собственный оператор и набор Custom Resource Definitions (CRD).

Ключевые принципы изоляции выстроены на трех уровнях:

1. Криптографическая идентичность сессии: каждому запущенному поду динамически присваивается кратковременный криптографический сертификат. Процессы внутри песочницы не знают логинов и паролей внешних систем — они знают лишь о локальных интерфейсах Cordium.
2. Динамический перехват трафика: локальный прокси-слой Octelium перехватывает все исходящие сетевые обращения (к базам данных PostgreSQL, MySQL, серверам SSH или внутренним REST API) и проверяет права на лету через движки Policy-as-Code (CEL и Open Policy Agent).
3. Беспривилегированный запуск (Rootless): поды песочниц работают исключительно от непривилегированного пользователя с ограничением системных вызовов через профили seccomp, исключая побег из контейнера на хост-ноду кластера.

Учетные данные подставляются внешним защищенным прокси-слоем непосредственно в момент рукопожатия протокола за пределами контейнера песочницы.

Описание песочницы и практический сценарий доступа

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

apiVersion: cordium.octelium.io/v1alpha1
kind: SandboxWorkspace
metadata:
  name: ai-agent-sandbox
  namespace: cordium-workspaces
spec:
  image: ghcr.io/octelium/workspace-standard:latest
  resources:
    limits:
      cpu: "2"
      memory: "4Gi"
    requests:
      cpu: "500m"
      memory: "1Gi"
  securityContext:
    runAsNonRoot: true
    readOnlyRootFilesystem: false
  secretlessAccess:
    enabled: true
    policies:
      - name: internal-postgres-readonly
        target: "db.internal.company.net:5432"
        role: "reporting_reader"
      - name: internal-api-gateway
        target: "https://api.internal.company.net"
        allowedPaths:
          - "/v1/metrics/*"
          - "/v1/health"

Когда агент или разработчик подключается к терминалу песочницы и обращается к целевой инфраструктуре, он использует стандартные клиентские утилиты, обращаясь к локальной петле (loopback), где прокси перенаправляет запрос в защищенный туннель:

# Подключение к базе данных через локальный защищенный интерфейс Cordium
# Пароль не требуется: прокси-слой Octelium автоматически валидирует права сессии
psql -h 127.0.0.1 -p 5432 -U reporting_reader -d analytics_db -c "SELECT count(*) FROM audit_logs;"

Даже если выполняемый скрипт сделает полный дамп памяти процесса, прочитает файл /proc/self/environ или выведет конфигурационные файлы, он не найдет пароля к рабочей базе данных — в окружении его просто нет.

Инженерные компромиссы и готовность к внедрению

Cordium лицензирован под открытой лицензией Apache-2.0, что делает его привлекательным решением для построения внутренних платформ разработки (Internal Developer Platforms, IDP). Однако внедрение технологии требует учета инфраструктурных затрат.

Во-первых, проксирование сетевых соединений вносит микроскопическую задержку (порядка единиц миллисекунд на установление TLS/TCP-сессии), что незаметно при интерактивной работе или отладке тестов, но требует калибровки при проведении нагрузочного тестирования с высокой частотой транзакций. Во-вторых, переход на Policy-as-Code требует предварительного описания сетевых политик: если сервису требуется доступ к новому API, его необходимо явно зарегистрировать в манифесте.

Тем не менее для команд, внедряющих агентные конвейеры кодогенерации и удаленные среды разработки (VS Code Server, Zed), Cordium устраняет самый опасный вектор атак, превращая изолированный контейнер в по-настоящему безопасную песочницу.