Netflix mostra atestação de workload para trocar identidade da nuvem por identidade própria no Amazon EMR

Uma única conta AWS não comporta dezenas de milhares de IAM roles, e a Netflix projeta operar data projects nessa ordem de grandeza. Esse limite de conta aparece logo no início do desenho de atestação de workload que a empresa adota para cargas Apache Spark no Amazon EMR, conforme artigo publicado no Netflix Tech Blog. O objetivo é trocar a identidade fornecida pelo provedor de nuvem por uma identidade interna de primeira classe — e fazer isso de forma verificável, sem transformar a troca em um ponto cego de segurança.

Dois sistemas de identidade em paralelo

Organizações que já operam há algum tempo costumam manter dois sistemas de identidade rodando lado a lado. O primeiro pertence ao provedor de nuvem e se materializa em IAM roles, instance profiles e execution roles. O segundo é próprio da empresa e é o que os serviços internos realmente consultam quando decidem se respondem a uma requisição.

A distinção não é burocrática. A identidade de nuvem autoriza o processo a operar recursos do provedor, como máquinas, buckets e filas. A identidade interna autoriza o processo a acessar sistemas corporativos, dados e serviços que não reconhecem a semântica do provedor. Em infraestrutura controlada pela própria equipe, é possível fazer o bootstrap da identidade interna de qualquer forma razoável, injetando credenciais ou chamando um serviço de identidade diretamente. Em managed compute, esse caminho desaparece: o provedor entrega ao processo uma cloud identity e nada além dela.

O limite do managed compute

O bootstrap de identidade em infraestrutura própria costuma envolver injetar um segredo ou acionar um serviço interno antes de o processo começar. Em managed compute, o processo recebe apenas a identidade de nuvem do provedor, e não há canal preexistente para obter a própria identidade corporativa.

Uma carga Spark gerenciada começa com uma AWS execution role e nenhuma identidade interna. No entanto, tudo o que o job precisa fazer dentro da empresa exige a identidade própria: ler uma coluna criptografada, avaliar ACLs de tabela, manter uma sessão interativa aberta por mais tempo do que um token de curta duração suporta. A troca em si é direta, segundo o texto da Netflix. O que exigiu trabalho de desenho foi torná-la confiável, de modo que o serviço de identidade tenha provas de que o processo que pede um certificado é mesmo o workload que diz ser. A empresa observa que muito pouco do que descreve é específico de Spark ou de EMR: o problema aparece em qualquer ambiente managed compute que entregue apenas identidade de provedor à aplicação.

Atestação: verificação antes do certificado

A autenticação serviço a serviço na Netflix roda sobre uma PKI privada chamada Metatron. Cada workload recebe um certificado X.509 de curta duração, e os serviços se autenticam mutuamente com mutual TLS. O certificado curto reduz a janela de exposição em caso de comprometimento da chave privada.

Um workload não pode simplesmente pedir um certificado. O Identity service só emite depois de se convencer de que o requisitante é realmente o workload que afirma ser. Essa etapa de verificação é a atestação. Em cada ambiente suportado — VMs, containers e functions —, a atestação se apoia em uma prova específica do ambiente, algo que a plataforma consegue checar por conta própria, sem depender apenas da palavra do requisitante. A distinção entre autenticar e atestar é estrutural: autenticar comprova a posse de uma credencial; atestar comprova que o ambiente ao redor sustenta essa credencial de forma verificável.

Data Project: a identidade que controla a mesa

O segundo conceito central é o Data Project, a unidade de propriedade de dados da Netflix. Um Data Project possui tabelas, tem um conjunto de usuários autorizados e carrega uma identidade própria. Quando um job executa, ele roda como o Data Project, não como a pessoa que o disparou.

Esse modelo mantém o controle de acesso em nível de tabela e a auditoria consistentes entre execuções agendadas e uso interativo. Se o job rodasse com a identidade do usuário que o lançou, políticas de tabela e trilhas de auditoria variariam a cada execução. Ao fixar a identidade no Data Project, a Netflix torna o comportamento previsível. A consequência para o managed compute é direta: o job precisa apresentar uma identidade interna desde o início, porque é com ela que as políticas de dados decidem o que liberar ou negar.

O mapeamento 1:1 que sustenta a tradução

O desenho descrito se apoia em uma decisão tomada fora do stack Spark. Cada identidade de Data Project é mapeada 1:1 para uma IAM role dedicada, e o serviço que detém os metadados de Data Project registra essa correspondência. O serviço que guarda os metadados do Data Project é quem registra a correspondência, o que evita que cada job precise descobrir a role por conta própria.

O mapeamento é o que torna a tradução possível entre os dois vocabulários de identidade. Uma afirmação no vocabulário do provedor — "este processo roda como a role R" — vira uma afirmação no vocabulário interno — "este processo é o workload W". Sem esse vínculo, não existe o que traduzir, e nenhuma criptografia resolve o impasse. O texto é taxativo: a parte difícil de unir dois sistemas de identidade raramente é o protocolo; é comprometer-se com um mapeamento e mantê-lo autoritativo ao longo do tempo.

Contas dedicadas e sharding determinístico

A objeção prática ao mapeamento 1:1 surge imediatamente. Uma única conta AWS não consegue acomodar dezenas de milhares de IAM roles, e a Netflix espera operar data projects na casa das dezenas de milhares. O limite não é cosmético: estourar a capacidade de roles por conta inviabilizaria o modelo direto, porque não haveria onde registrar a correspondência de cada Data Project.

A resposta foi distribuir as roles de data project de forma determinística por um pequeno pool de contas dedicadas. Além de escalar bem além do número projetado de projetos, o sharding tem um efeito colateral relevante: as workload roles ficam do outro lado de uma fronteira de conta em relação aos control planes que as lançam. Isso reduz o acoplamento e limita o raio de impacto de um comprometimento no plano de controle.

Os cinco componentes do fluxo

O artigo lista cinco componentes que participam da troca de identidade. O control plane é o único serviço autorizado a lançar jobs Spark. Ele resolve a IAM role do Data Project, monta e assina um workload metadata payload e submete o job com essa role como execution role. A signing key usada para assinar o payload é emitida exclusivamente para esse propósito, o que limita o que uma chave comprometida conseguiria fazer.

O Data Project service é a autoridade do mapeamento entre identidade e role. O Identity service recebe os pedidos de atestação, verifica cada um e emite certificados quando a prova confere. O gancho dentro do processamento fica com um Spark plugin: a interface de plugin adicionada no Spark 3.0+ tem componentes no driver e nos executors, inicializados durante o bootstrap desses processos. Essa inserção no ciclo de vida permite que a troca de identidade aconteça antes de o job começar a acessar dados. Fora do stack, AWS STS atua como notário — um papel incomum para o serviço, cuja função usual não é validar identidade entre sistemas.

O texto da Netflix detalha os componentes e o papel de cada um em Trading a Cloud Identity for Your Own, mas o trecho apurado termina antes da descrição completa do protocolo após o primeiro passo.

O que muda na prática e onde estão as limitações

Na prática, o desenho transforma a identidade de nuvem em uma ponte para a identidade interna. O workload não precisa conhecer segredos de bootstrap nem os serviços internos precisam passar a confiar no provedor de nuvem como autoridade. O mapeamento centralizado mantém os jobs atrelados ao Data Project, preservando auditoria e políticas de acesso consistentes entre execuções agendadas e interativas.

As limitações começam pela dependência do mapeamento central. Se a correspondência entre Data Project e IAM role ficar inconsistente ou deixar de ser mantida como fonte autoritativa, a tradução falha — e o artigo é explícito ao dizer que nenhuma criptografia compensa essa falha. Há também a restrição de capacidade de roles por conta, que força o sharding em múltiplas contas e adiciona superfície operacional. O fluxo inteiro depende de um control plane como único ponto autorizado a lançar jobs, o que concentra responsabilidade e exige proteção extra da signing key. Como o material apurado não descreve o protocolo completo após o primeiro passo, detalhes da verificação final permanecem em aberto para quem quiser implementar algo semelhante.

A abordagem faz sentido quando a organização já opera um PKI interno, precisa de identidade de workload em managed compute e consegue comprometer-se com um mapeamento identidade-para-role de longo prazo. Não faz sentido quando o problema é apenas conceder acesso temporário a recursos da nuvem: nesse caso, a identidade do provedor já resolve, e a complexidade adicional de atestação, sharding de contas e control plane exclusivo não se justifica.