Инженер сменил команду, его права доступа обновили — и ночной пайплайн перестал работать. В Netflix эта проблема возникала на масштабе миллионов таблиц и десятков тысяч задач.
Чтобы не чинить доступ после каждой перестановки в командах, в компании создали Data Projects: связанные данные и процессы объединяют в проект, а задачи запускаются от его имени. Я подумал, что тема острая, поэтому перевел разбор команды Netflix — про права, технические учетные записи и миграцию существующих процессов.
Почему управление отдельными таблицами перестало работать
Платформа данных Netflix огромна. В нашем хранилище миллионы таблиц, а в системах оркестрации — десятки тысяч задач, которые запускаются по расписанию. За каждым таким ресурсом стоит инженер, команда или инициатива. И для каждого нужно решить, кому разрешен доступ и от чьего имени будут день за днем выполняться задачи.
Годами наши инструменты управления доступом работали на уровне отдельных ресурсов. У каждой таблицы был собственный список контроля доступа — ACL. Каждый рабочий процесс, или workflow, запускался от имени создавшего его инженера.
Но сотрудники меняют команды и роли, а иногда уходят из компании. В такой среде детальная модель управления регулярно давала сбой по двум причинам.
Проблема 1. Права не успевали за изменениями в командах
Представьте, что ваша команда отвечает за несколько сотен таблиц. После реорганизации к вам присоединяется соседняя команда, и таблиц становится еще на несколько сотен больше. Теперь нужно найти ACL каждой таблицы, разобраться, у кого должен остаться доступ, и обновить их по одному.
Умножьте эту работу на каждую реорганизацию во всех командах компании. Получаются две проблемы (еще две внутри первой).
Поддержку заваливают запросами. Непропорционально большая часть обращений была связана с массовым изменением прав на таблицы после организационных перестановок. Инструменты самообслуживания и рекомендации уже существовали, но команды пользовались ими непоследовательно. Data Projects превратил такое решение из необязательного инструмента в базовую часть платформы данных.
Доступ выдают слишком широко. Вместо того чтобы поддерживать детальные ACL, команды нередко открывали таблицы всей компании. Смысл контроля доступа при этом терялся.
Проблема 2. Рабочие процессы зависели от учетных записей сотрудников
Задачам по расписанию и асинхронным процессам — workflow в Maestro, заданиям переноса данных, Spark-пайплайнам — нужна учетная запись, от имени которой они будут выполняться. Исторически это была учетная запись человека, который создал процесс.
Но привязка к человеку недолговечна. Сотрудник переходит в другую команду, получает новые обязанности или увольняется. Его права меняются, и задачи, запущенные от его имени, падают.
Приходилось переключать их на учетную запись коллеги. А у того неизбежно оказывался другой набор разрешений: исправляешь одну ошибку доступа — обнаруживается следующая. Потом и этот коллега меняет роль, и все повторяется.
Что такое Data Project
Мы создали Data Projects, чтобы решить обе проблемы. В основе проекта две составляющие:
Логический контейнер связанных ресурсов: таблиц, рабочих процессов и других объектов платформы данных. Их можно просматривать и администрировать вместе.
Отдельная устойчивая техническая учетная запись, от имени которой могут выполняться асинхронные задачи и процессы по расписанию. Ее жизненный цикл не зависит от конкретного сотрудника, а пользователи с нужными полномочиями могут действовать от ее имени.
Мы поднимаем управление с уровня отдельного ресурса на уровень осмысленной группы — проекта. Вместо того чтобы выдавать права на 500 таблиц по одной, можно управлять доступом к проекту, в который входят эти таблицы.
Сначала мы сосредоточились на правах доступа и учетных записях для выполнения задач. Но сама абстракция применима гораздо шире. Этот потенциал — одна из причин, по которым в нее стоит вкладываться.
Как устроены разрешения и роли
У каждого Data Project есть набор назначений доступа, которыми управляет команда-владелец. Доступ можно назначить пользователю, группе, приложению или заданию непрерывной интеграции — CI. Каждому назначению соответствует роль: она определяет, что получатель может делать в проекте.
Например, Contributor может читать и изменять ресурсы проекта, а Viewer — только читать. Когда человек присоединяется к команде или уходит из нее, достаточно изменить одно назначение на уровне проекта. Переписывать сотни ACL не нужно.
Один проект — общая учетная запись для выполнения задач
Для каждого Data Project создается учетная запись приложения Netflix. При необходимости проект также получает роль AWS IAM. Вместе они образуют общий контур, который делает выполнение задач устойчивым к изменениям в команде.
От имени учетной записи проекта в Netflix выполняются его асинхронные задачи, например workflow в Maestro. Она принадлежит проекту, а не отдельному человеку.
Роль IAM нужна для специализированных сценариев в AWS, например Spark-заданий на Amazon EMR. Важно, что с использованием IAM-роли можно криптографически защищенным способом получить возможность действовать от имени проекта в Netflix.
Участники с привилегированными ролями тоже могут действовать от имени проекта: тестировать код и искать ошибки со своего рабочего ноутбука или из интерактивного блокнота в Jupyter Notebook. В обоих случаях команды выполняются от имени проекта, с той же учетной записью, что и задача по расписанию.
Гравитация: новые ресурсы сами попадают в проект
Еще одно удобное свойство Data Projects — гравитация (это мы его так называем). Если задача, выполняющаяся от имени проекта, создает новый ресурс, он автоматически добавляется в этот проект.
Например, workflow в Maestro создал три таблицы — все три становятся частью его проекта.
Проект превращается в центр притяжения для всего, что создается от его имени. Ресурсы организуются автоматически, как следствие обычной работы платформы. Не приходится позже выяснять, где находятся связанные объекты и как получить к ним доступ.
Как Data Projects защищают процессы обработки данных
Maestro — основной оркестратор Netflix для пакетной аналитики. Через него запускаются ETL-пайплайны по расписанию, перенос данных, обучение моделей и другие задачи.
Подробнее об оркестраторе — Maestro: Data/ML Workflow Orchestrator at Netflix.
Workflow может запускаться по расписанию без участия своего автора. Поэтому Maestro имеет статус Trusted Workload Manager (TWM): он уполномочен выпускать новые токены идентификации от имени задач, которыми управляет.
От чьего имени выполняется процесс, важно на каждом этапе. В рамках одного запуска могут проверяться ACL таблиц в Secure Data Warehouse, политики авторизации для ресурсов Netflix и IAM-политики AWS. Если учетная запись, на которую опирается процесс, ненадежна, ненадежным становится весь процесс.
Что ломалось при привязке к пользователю
Как было раньше: стандартным вариантом было выполнение workflow с учетными данными On-Behalf-Of — OBO, например maestro OBO alice@netflix.com. В такой модели процесс получал совокупность полномочий Maestro и пользователя, но вместе с этим его разрешения оказывались привязаны к конкретному человеку.
Когда сотрудник менял команду или уходил из Netflix, процесс ломался. Владение можно было передать коллеге, но у него редко оказывался точно такой же доступ.
Пока разрешения приводили в порядок, workflow мог не работать несколько дней. При десятках тысяч задач по расписанию, многие из которых критичны для бизнеса, такая модель перестала быть приемлемой.
Как помогает устойчивая учетная запись проекта
Data Projects заменяет привязку к пользователю устойчивой учетной записью приложения Netflix, которой владеет команда. Она не переходит в другую команду, не уходит в отпуск и не увольняется.
Проект объединяет связанные workflow, таблицы, секреты и другие ресурсы под общей учетной записью. Прежде чем запустить процесс от ее имени, Maestro проверяет, имеет ли вызывающая сторона доступ к проекту.
Таблицы, созданные во время выполнения, благодаря гравитации автоматически связываются с проектом и наследуют его правила доступа без дополнительной настройки.
Секреты подчиняются политикам проекта, поэтому при смене владельца учетные данные не остаются без доступного управления.
Доступ настраивается один раз на уровне проекта. Разрозненные пользовательские разрешения для каждого ресурса, к которому обращается workflow, больше не нужны.
В результате модель становится устойчивой, поддается аудиту и выдерживает организационные изменения, неизбежные в компании такого масштаба.
Где это уже работает
Многие Data Projects в продакшене уже объединяют десятки тысяч ресурсов. Вот два примера.
Streaming Quality of Experience. Один из основных пайплайнов наблюдаемости отслеживает качество просмотра — QoE. Раньше его бесперебойная работа зависела от того, какой инженер владел соответствующими workflow. Теперь он выполняется от имени проекта и не зависит от изменений состава команды.
Member Analytics. Аналитические модели и ETL-процессы для продуктов, работающих с данными пользователей. Доступ к этой критичной для бизнеса аналитике теперь управляется на уровне проекта, а не отдельно для сотен таблиц и рабочих процессов.
В целом Data Projects становится способом организации целых аналитических направлений. Раньше команды поддерживали собственные политики, ситуативные списки разрешений и устные знания о том, кому что положено. Теперь ответ сосредоточен в проекте.
Как перевести рабочие процессы в Data Projects
Для подключения workflow нужно выполнить три шага:
Создать проект для логической группы ресурсов или выбрать уже существующий подходящий проект.
Назначить нужным людям и группам соответствующие роли.
Настроить workflow так, чтобы он выполнялся от имени проекта.
Благодаря гравитации новые ресурсы, созданные процессами проекта, попадут в него автоматически.
Со старыми процессами сложнее: прежде чем менять учетную запись для выполнения, проекту нужно выдать все необходимые разрешения. Сейчас мы работаем над инфраструктурой, которая отслеживает, к каким ресурсам обращаются существующие workflow. На основе этих данных можно будет рекомендовать точные изменения прав для проекта, в который они переезжают.
Наша цель — сделать Data Project стандартным вариантом запуска любых асинхронных задач.
Что дальше
Data Projects начинался как инициатива Analytics Platform в ответ на конкретные проблемы хранилища данных. Но лежащие в его основе идеи применимы и за его пределами.
В будущем Projects — уже не только Data Projects — могут стать полноценной концепцией платформы для разных типов ресурсов. В их число входят данные, программные ресурсы — GitHub-репозитории, приложения Spinnaker, Docker-образы, — а также ресурсы студийного производства: контент, пайплайны и преобразования.
Параллельно мы развиваем четыре направления:
Подбор необходимого объема прав. Поверх политик авторизации мы добавляем слой, который автоматически корректирует разрешения по фактическому использованию. Так мы убираем лишний доступ и предотвращаем постепенное накопление полномочий.
Другие задачи на уровне проекта. Проект удобен не только для управления доступом и учетными записями, но и для учета затрат, отображения состояния и других сводных показателей.
Интерактивные сценарии. Мы расширяем использование учетных записей проектов за пределы задач по расписанию — например, на разовые запросы через Data Portal.
Журналы активности и аудит. Единая история изменений разрешений, ресурсов и версий workflow на уровне проекта.
Почему единицей управления стал проект
Data Projects вырос из простого наблюдения: на масштабе Netflix управлять доступом и выполнением задач на уровне отдельного ресурса или отдельного человека уже не получается. Нужна более крупная и устойчивая единица, которая соответствует тому, как сами команды воспринимают свою работу и ответственность.
Такой единицей стал проект. По мере распространения этой концепции за пределы хранилища данных мы рассчитываем, что она станет одной из основ организации инженерной работы в Netflix, а не только способом упорядочить данные.