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

Детерминированные сборки необходимы для аттестации рабочей нагрузки в доверенной среде выполнения (TEE) для персонализации на устройстве (ODP), общедоступной в Google Cloud как конфиденциальное пространство (CS).

Образы рабочей нагрузки должны генерировать детерминированный хэш изображения, который может использоваться CS для аттестации рабочей нагрузки (в которой используется архитектура процедур удаленной аттестации (RATS) NIST RFC 9334 ).

В этом документе будет рассмотрена реализация и поддержка детерминированных сборок в репозитории odp-federatedcompute . Службы агрегатора ODP и средства обновления моделей будут работать в конфиденциальном пространстве. Репозиторий поддерживает детерминированные сборки для всех наших сервисов, которые необходимы для производственных сценариев использования.

Детерминированные сборки

Детерминированные сборки состоят из двух основных компонентов:

1. Компиляция необходимых бинарников. Сюда входят jar-файлы, общие библиотеки и метаданные.
2. Базовый образ и зависимости времени выполнения. Базовый образ среды выполнения, используемый для выполнения скомпилированных двоичных файлов.

На данный момент репозиторий объединенных вычислений ODP поддерживает следующие типы рабочих нагрузок:

• Рабочие нагрузки Java + Spring
  • TaskAssignment, TaskManagement, Коллектор
• Java + Spring с рабочими нагрузками тензорного потока JNI
  • Обновление моделей, агрегатор
• Рабочие нагрузки Python
  • TaskBuilder

Зависимости

В следующем списке приведены зависимости, на которые опирается ODP для поддержания детерминированности и доступности:

• Базель
• GitHub
• Мавен
• ПиПи
• Снимки Debian
• Реестр DockerHub
• Реестр контейнеров Google (GCR)

Детерминированные рабочие нагрузки

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

Снимки Debian

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

• Системные заголовки и библиотеки
• Архитектура системы
  • linux_x86_64
  • Дебиан
• компилятор С++
  • готовый Clang+LLVM 16

Рабочие нагрузки Java Spring

remotejdk_17 компании Bazel используется для предоставления герметичной Java для компиляции. Другие зависимости Java управляются и определяются в файле WORKSPACE .

Рабочие нагрузки Java Spring компилируются в jar-файл с именем <service>_application.jar . Баночка содержит:

• Файлы классов Java
• META-INF/
  • Данные манифеста Базеля
• build-data.properties
  • Базельские данные сборки
• BOOT-INF/
  • Упакованные зависимости jar, созданные с помощью Rules_spring .

Слои изображения

Образ рабочей нагрузки Java Spring состоит из двух слоев:

• Базовый слой изображения
  • Базовый образ Java: gcr.io/distroless/java17-debian11
• Уровень рабочей нагрузки
  • binary_tar.tar
    • <service>_application.jar

Конфигурация изображения

• Входная точка
  • java -jar <service>_application.jar

Рабочие нагрузки JNI Tensorflow

Рабочие нагрузки JNI Tensorflow построены на основе рабочих нагрузок Java Spring. Герметичный набор инструментов Clang+LLVM Bazel предоставляется с использованием предварительно созданного Clang+LLVM 16 с системным корнем, предоставленным образом моментального снимка Debian, для компиляции машинного кода.

Рабочие нагрузки JNI компилируются в общую библиотеку с именем libtensorflow.so вместе с <service>_application.jar .

Слои изображения

Образ рабочей нагрузки тензорного потока JNI состоит из нескольких слоев:

• Базовый слой изображения
  • Базовый образ Java: gcr.io/distroless/java17-debian11
• Уровни зависимостей пакета Debian. Слои создаются с использованием архивов deb, загруженных из debian-snapshot и переупакованных как слои изображений.
  • libc++1-16_amd64.tar
  • libc++abi1-16_amd64.tar
  • libc6_amd64.tar
  • libunwind-16_amd64.tar
  • libgcc-s1_amd64.tar
  • gcc-13-base_amd64.tar
• Уровень рабочей нагрузки
  • binary_tar.tar
    • <service>_application.jar
    • libtensorflow-jni.so
    • libaggregation-jni.so

Конфигурация изображения

• Метки (только для изображений, созданных для работы в TEE)
  • "tee.launch_policy.allow_env_override": "FCP_OPTS"
    • Позволяет устанавливать переменную среды FCP_OPTS в конфиденциальном пространстве . Рабочая нагрузка будет использовать FCP_OPTS при запуске для настройки необходимых параметров.
    • Переменная среды FCP_OPTS устанавливается при запуске образа (а не при его сборке) для обеспечения детерминированности сборки.
  • "tee.launch_policy.log_redirect": "always"
  • "tee.launch_policy.monitoring_memory_allow": "always"
• Входная точка
  • java -Djava.library.path=. -jar <service>_application.jar

Рабочие нагрузки Python

Rules_python от Bazel используется для обеспечения герметичного набора инструментов Python 3.10. Заблокированный файл требований к pip используется для детерминированной выборки зависимостей pip. Образ моментального снимка Debian обеспечивает выборку детерминированных дистрибутивов на основе совместимости платформ и предоставляет набор инструментов C++ для компиляции исходных дистрибутивов.

Рабочие нагрузки Python будут упакованы в набор загруженных пакетов pip, дистрибутив Python 3.10, исходный код ODP Python и сценарий запуска Python.

• <service>.runfiles/
  • Дистрибутив Python хранится в python_x86_64-unknown-linux-gnu/
  • Исходный код хранится в com_google_ondevicepersonalization_federatedcompute/
  • Пакеты Pip хранятся в pypi_<dependency_name>/
• <service>.runfiles_manifest
  • Файл манифеста для каталога <service>.runfiles/
• <service>
  • Скрипт Python для запуска рабочей нагрузки Python с использованием файлов запуска.

Слои изображения

Образ рабочей нагрузки Python состоит из четырех слоев:

• Базовый слой изображения
  • Базовый образ Python python:slim
• Уровень переводчика
  • interpreter_layer.jar
    • <service>/<service>.runfiles/python_x86_64-unknown-linux-gnu/**
• Слой пакетов
  • packages_layer.jar
    • <service>/<service>.runfiles/**/site-packages/**
• Уровень рабочей нагрузки
  • app_tar_manifest.tar
    • Содержит исходный код, сценарий запуска и манифест.
      • <service>/<service>.runfiles_manifest
      • <service>/<service>
      • <service>/<service>.runfiles/com_google_ondevicepersonalization_federatedcompute/**

Конфигурация изображения

• Входная точка
  • /<service>/<service>

Создание изображений

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

Предварительные условия

• Базель 6.4.0
  • Требуется установка Java и C++.
• Докер

Процедура

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

• docker_run.sh
  • docker_run.sh создаст образ docker из файла docker, смонтирует рабочий каталог, смонтирует демон docker хоста и запустит docker с помощью предоставленной команды bash. Любые переменные, переданные перед командой bash, будут рассматриваться как флаги запуска Docker.
• build_images.sh
  • build_images.sh запустит bazel build для всех изображений и выведет сгенерированные хэши изображений для каждого построенного образа.

Создайте все изображения

./scripts/docker/docker_run.sh "./scripts/build_images.sh"

Ожидаемые хэши изображений для каждого выпуска можно найти в разделе odp-federatedcompute Releases GitHub .

Публикация изображений

Публикация настраивается с использованием правил oci_push Bazel. Для каждого сервиса целевой репозиторий должен быть настроен для всех:

• агрегатор
• коллектор
• model_updater
• задача_назначение
• управление задачами
• Планировщик заданий
• Task_Builder

Опубликовать одно изображение

./scripts/docker/docker_run.sh "bazel run //shuffler/services/<servicename_no_underscore>:<servicename_with_underscore>_image_publish"

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

Построенные изображения

Все созданные изображения должны храниться и размещаться у создателя, например, в реестре артефактов GCP .