Netflix TechBlog | Medium на русском
Подписаться
Обмен облачной идентификацией на собственную: аттестация рабочих нагрузок на управляемых вычислительных ресурсах
Организации часто поддерживают две параллельные системы идентификации: одну от облачных провайдеров, таких как AWS, и другую для внутренних сервисов. В этой статье подробно рассказывается, как рабочие нагрузки Apache Spark на Amazon EMR устраняют этот разрыв, позволяя им получить первоклассную внутреннюю идентификацию из исходной облачной идентификации. Netflix использует частную PKI под названием Metatron для аутентификации между сервисами через взаимный TLS, что требует процесса аттестации для проверки идентификаторов рабочих нагрузок. Они также используют концепцию "Проект данных", который владеет данными и имеет свою собственную идентификацию, обеспечивая согласованность в управлении доступом и аудите.Основная задача заключается в преобразовании облачной роли выполнения AWS в необходимую внутреннюю идентификацию для заданий Spark на управляемых вычислительных ресурсах. Это решение устанавливает прямое соответствие один к одному между каждым идентификатором Проекта данных и выделенной ролью IAM, при этом сервис Проекта данных выступает в качестве авторитета для этого соответствия. Это соответствие имеет решающее значение для преобразования утверждений из лексикона облачного провайдера в лексикон организации. Для решения проблемы масштабируемости управления многочисленными ролями IAM эти роли детерминированно шардируются по небольшому пулу выделенных учетных записей AWS.В процессе задействованы пять компонентов: плоскость управления (запускает задания и подписывает метаданные), сервис Проекта данных (управляет соответствием идентификатор-роль), сервис идентификации (проверяет аттестации и выдает сертификаты), плагин Spark (интегрируется в загрузку процесса) и AWS STS (действует как нотариус). Процесс начинается с того, что плоскость управления подписывает пакет метаданных, содержащий сведения о рабочей нагрузке. Затем плагин драйвера Spark использует учетные данные AWS для создания предварительно подписанного URL-адреса из AWS STS, доказывая владение облачной идентификацией.Затем сервис идентификации подтверждает эти два независимых утверждения: роль, идентифицированную AWS по предварительно подписанному URL-адресу, и подписанные метаданные от плоскости управления. Если они совпадают, для рабочей нагрузки выдаются сертификаты. Это подтверждение имеет жизненно важное значение, поскольку ни одно из утверждений само по себе недостаточно; утверждение провайдера является подделываемым, но недостаточно детализированным, в то время как утверждение плоскости управления хорошо детализировано, но потенциально может быть воспроизведено. Система решает проблему распараллеливания для исполнителей, позволяя драйверу аттестоваться один раз и безопасно распределять учетные данные. Сертификаты имеют короткий срок действия и обновляются посредством повторяемого процесса аттестации внутри JVM драйвера. Модель доверия гарантирует, что ни один участник не сможет выдать идентификацию независимо, и рабочая нагрузка сама никогда не требуется для подтверждения своей легитимности.