Lakekeeper Catalog for Apache Iceberg — практическое руководство по внедрению и эксплуатации
Lakekeeper — это REST-каталог для Apache Iceberg, написанный на Rust и распространяемый под лицензией Apache 2.0. Он выступает «ядром» lakehouse-платформы: хранит метаданные Iceberg, управляет правами и выдает безопасные делегированные доступы к объектным хранилищам (S3/ADLS/GCS/совместимые). Вокруг него легко строить многопользовательские и мульти-тенант окружения с четким разграничением доступа, аудируемыми изменениями и интеграцией с корпоративными IdP.
Базовая теория: что делает REST-каталог в Iceberg
Iceberg разделяет данные (в объектном хранилище) и метаданные (табличные версии, снапшоты, схемы, партиции). REST-каталог — стандартный API для операций list/create/drop/alter на таблицах/пространствах имен и для выдачи параметров доступа к данным. Lakekeeper реализует этот стандарт и добавляет управленческие возможности (права, роли, проекты, политики) через отдельный Management API, а также сервисы делегирования доступа к хранилищу (вендед-учетные данные и удаленную подпись запросов S3).
Архитектура Lakekeeper: компоненты и потоки
Минимальный продакшн-периметр Lakekeeper включает:
- Persistence backend (каталог): сейчас поддерживается PostgreSQL (рекомендуется отказоустойчивый кластер).
- Object storage: S3/S3-совместимые, Azure Data Lake Gen2, Google Cloud Storage.
- IdP (OpenID/OAuth2) и/или Kubernetes SA: для аутентификации пользователей и сервисов.
- Authorization system: по умолчанию OpenFGA (грантовая модель с наследованием).
-
(Опционально) Secret store (Vault-совместимые), event store (NATS/Kafka), data-contract-система.
REST-каталог обслуживается по /catalog/*, а административные операции — по /management/*. Для S3 реализован endpoint удаленной подписи /<warehouse-id>/v1/aws/s3/sign.
Продакшн-заметки
Рекомендуются внешний HA-Postgres, отдельные URLы для чтения/записи, несколько инстансов Lakekeeper, TLS через реверс-прокси/Ingress и совместное размещение OpenFGA рядом с Lakekeeper ради задержек. Есть официальный Helm-чарт.
Аутентификация (AuthN)
Lakekeeper не хранит и не выдает собственных API-ключей: он опирается на IdP, поддерживает любой OpenID/OAuth2 провайдер и нативно умеет аутентифицировать Kubernetes-сервис-аккаунты. Для машинных пользователей применяется OAuth2 Client Credentials, для людей — Authorization Code/Device Code (до нативной поддержки в клиентах Iceberg можно получить токен через UI Lakekeeper). Рекомендуется проверка audience и настройка subject_claim (например, oid в Entra ID).
Авторизация (AuthZ) и модели прав
По умолчанию Lakekeeper использует OpenFGA и предоставляет гранты на уровне server/project/warehouse/namespace/table/view/role с двусторонним наследованием (вниз — права распространяются от контейнера к детям, вверх — навигационные права, чтобы «видеть путь» к выданному ресурсу). Для высокорегламентных сред есть Managed Access: владелец объекта теряет право делегировать доступ, а раздачу прав централизует безопасность. Для Trino доступна «мостовая» интеграция через OPA: сам Trino может применять те же политики, что и Lakekeeper.
Профили хранилищ и делегирование доступа
S3 и S3-совместимые (MinIO, Cloudflare R2, др.)
- Credential vending (STS): Lakekeeper генерирует краткоживущие учетные данные на основе доверенного role assumption (AWS) или аналогов у совместимых S3.
- Remote signing: альтернативно Lakekeeper подписывает запросы к S3 на лету.
- Поддерживаются system identities (подтягивание AWS-кредов из окружения/метадаты), но настоятельно рекомендуется external-id в trust-политике роли.
- Для Cloudflare R2 используются R2-API-токены; на момент написания — требуются права Admin Read & Write на выдачу temp-credentials.
Azure Data Lake Storage Gen2
Доступна аутентификация через App Registration (Client Credentials) и System/Managed Identity (включается флагом окружения). Требуются роли Storage Blob Data Contributor/Delegator на нужный контейнер.
Google Cloud Storage
Поддерживаются Service Account Key и System Identity (включается флагом окружения). С версии 0.8.2 поддержаны иерархические пространства имен GCS.
Совместимость с движками (Trino/Spark/PyIceberg/StarRocks)
Все клиенты Iceberg REST поддерживаются.
- Spark: поддерживает credential vending для всех типов хранилищ, поэтому креды хранения в Spark не требуются; можно выбирать «vended-credentials» или «remote-signing» заголовком X-Iceberg-Access-Delegation.
- Trino: vended-credentials для S3, а для Azure/GCS — указывать собственные креды в Trino (на момент публикации). Для shared-Trino два варианта: OAuth2 token exchange (RFC 8693) или OPA-мост с принудительным применением Lakekeeper-политик на уровне Trino. Рекомендуется nested-namespace-enabled и unique-table-location при soft-delete.
Эксплуатация: production checklist кратко
- Внешний HA-Postgres, раздельные READ/WRITE DSN, регулярные бэкапы.
- Несколько экземпляров Lakekeeper, Helm-чарт, liveness/readiness, /health.
- Включить аутентификацию (OPENID_PROVIDER_URI), настроить OPENID_AUDIENCE и OPENID_SUBJECT_CLAIM.
- Секреты шифруются ключом PG_ENCRYPTION_KEY (или внешний secret store).
- Для OpenFGA — колокация узлов (podAffinity в Helm).
- Разделяйте склады (warehouse) по уникальным префиксам в хранилище и разным учетным данным.
- TLS — через reverse proxy/Ingress (Nginx/Envoy/любой Ingress).
Пошаговый пример: S3 + Keycloak + Trino (multi-tenant)
Сценарий: один проект, несколько warehouse (prod/dev), общий Trino, пользователи в Keycloak.
- Деплой Lakekeeper через Helm, внешний Postgres-кластер (CloudNativePG или аналог), OpenFGA — рядом. Включите HTTPS на Ingress.
- Инициализация: bootstrap/migrate (подготавливает БД/авторизацию), создайте Project и Warehouses (dev/prod) с уникальными префиксами.
- AuthN: в Keycloak — публичный клиент для UI Lakekeeper (аудитория lakekeeper) и machine-client для Trino (Client Credentials). В LAKEKEEPER__OPENID_* укажите провайдера, audience, subject_claim.
- S3-доступ: создайте IAM-роль под каждый warehouse, включите external-id в trust-политике и ограничьте доступ префиксом бакета. В Lakekeeper укажите assume-role-arn, при необходимости используйте system identity.
- Trino-каталог: тип rest, URI Lakekeeper, имя warehouse, включите vended-credentials-enabled. Для OAuth2 — iceberg.rest-catalog.security=OAUTH2 и параметры токен-эндпойнта и client-secret. Для Azure/GCS — добавьте storage-креды в Trino.
- Права: создайте роли (data_admin/analyst), назначьте гранты на уровне namespace/table. Для зоны с жестким контролем включите Managed Access на warehouse/namespace.
- Работа: создавайте таблицы без ручного location (Lakekeeper проверит корректность путей и пустоту директорий, чтобы исключить «пересечения» данных и утечки через делегированные креды).
Паттерны эксплуатации и автоматизации
- Soft deletion и защита от PURGE: включайте soft-delete на warehouse; для S3 можно «протолкнуть» в клиенты запрет удаления (s3.delete-enabled=false), чтобы не нарушить восстановление; для maintenance-процедур включайте удаление точечно.
- Protection/Force/Recursive: помечайте важные сущности «защищенными», используйте рекурсивное удаление осознанно, а force=true — только в административных сценариях.
- События изменений (CDC метаданных): Lakekeeper умеет отправлять CloudEvents в Kafka/NATS — удобно для актуализации кэшей, DQ-проверок, триггеров обслуживания таблиц.
- OPA-bridge для Trino: в общих кластерах используйте OPA-мост, но минимизируйте «root»-доступы к Trino/OPA: эти сервисы содержат высокопривилегированные креды.
Типовые ошибки и риски — и как их избежать
- Одинаковый префикс бакета для разных warehouse. Риск утечки через временные креды. Решение: уникальные пути и отдельные учетные данные на warehouse.
- Spark + DROP TABLE … PURGE при soft-delete. Spark может удалять файлы сам — восстановление невозможно. Решение: не использовать PURGE; включать push-s3-delete-disabled, а для обслуживания явно разрешать удаление.
- IdP без audience/неверный subject_claim. Токены «для других приложений» могут проходить; права «поедут». Решение: всегда задавать OPENID_AUDIENCE и OPENID_SUBJECT_CLAIM.
- Trino без поддержки vending для Azure/GCS. Потребуются статические креды в Trino. Решение: учесть в IaC/секрет-менеджменте.
- Cloudflare R2 токен с недостаточными правами. Временные креды могут не выдаваться. Решение: на текущий момент требуются Admin Read & Write для temp-credentials.
- Разнесенный OpenFGA. Высокие задержки на проверку прав. Решение: колоцировать FGA с Lakekeeper (podAffinity).
- TLS и периметр. Lakekeeper сам TLS не терминирует. Решение: шифруйте через reverse-proxy/Ingress.
«Вопрос — ответ»
Q: Можно ли запускать без аутентификации?
A: Для тестовых стендов да (есть минимальные compose/helm примеры без Auth), но в продакшн рекомендуется включать OpenID/Kubernetes-auth и аудит.
Q: Какие IdP поддерживаются?
A: Любой OpenID/OAuth2 (Keycloak, Entra ID, Google), плюс нативная аутентификация Kubernetes SA.
Q: Как разграничивать доступ в общем Trino?
A: Либо OAuth2 token exchange (RFC 8693) так, чтобы sub соответствовал реальному пользователю, либо OPA-bridge в Trino с применением Lakekeeper-политик.
Q: Какие хранилища поддержаны и как выдаются доступы?
A: S3/S3-совместимые (включая Cloudflare R2), ADLS Gen2, GCS. Доступ делегируется через временные креды (vending) или удаленную подпись (S3).
Q: Что с резервированием и отказоустойчивостью?
A: HA-Postgres, несколько инстансов Lakekeeper, бэкапы, TLS, колокация OpenFGA.
Q: Можно ли хранить секреты вне Postgres?
A: Да, поддерживаются Vault-совместимые secret-store.
Чек-лист внедрения (короткий)
- Спроектируйте проекты/warehouses/namespaces и модель ролей.
- Разверните HA-Postgres, Lakekeeper (Helm), OpenFGA рядом, TLS/Ingress.
- Включите AuthN (OpenID/K8s), задайте OPENID_AUDIENCE и OPENID_SUBJECT_CLAIM.
- Создайте warehouse с уникальными префиксами и делегированием доступа (STS/Managed Identity).
- Подключите движки (Spark/Trino) и убедитесь, что vending/remote-signing работают.
- Включите Managed Access там, где нужна централизованная раздача прав.
- Настройте soft-delete, push-s3-delete-disabled и процедуры обслуживания таблиц.
- Включите события (Kafka/NATS) для DQ/обслуживания.
- Проведите пентест/секр. аудит: root-доступы в Trino/OPA, секреты, trust-политики ролей.
- Наблюдаемость: health-пробы, алерты OpenFGA/DB, метрики latency проверок прав.
Lakekeeper закрывает ключевые задачи современного lakehouse: стандартный REST-каталог Iceberg, тонкое разграничение доступа, безопасное делегирование к объектным хранилищам и интеграция с IdP/Kubernetes. Он снимает с команд рутину по «расшиванию» движков и облачных политик, сохраняя нейтральность к облаку и к вычислительному движку. При корректной постановке IdP/ролей/префиксов и соблюдении production-гайдов Lakekeeper — надежный фундамент для промышленной платформы данных.
