Como a Snyk está padronizando estratégias de autenticação com o Gloo Edge

A Snyk oferece suporte a várias estratégias de autenticação (authN) em suas APIs. Historicamente, as chaves de API eram a principal forma de authN, mas, mais recentemente, passamos a oferecer suporte à authN com JWTs assinados, gerados por uma integração com OAuth. Atualmente, isso é usado em nossas integrações com AWS CodePipeline e Bitbucket.

No início, a Snyk adotou uma arquitetura hub and spoke, com um monólito central responsável pelas decisões de authN. Isso funcionou muito bem enquanto a Snyk encontrava seu espaço no mercado e iterava rapidamente. Mas, à medida que a organização e sua base de clientes cresceram, também aumentou a demanda por uma arquitetura orientada a serviços (SOA). No entanto, essa mudança arquitetural exigiria que cada serviço tomasse decisões de authN. Ou seja, cada serviço precisaria conhecer várias estratégias de autenticação, o que se tornaria trabalhoso e difícil de escalar com o tempo.

Para viabilizar nossa transição para uma SOA, concluímos que a abordagem mais segura e pragmática seria ter uma única autoridade para normalizar as estratégias de authN em um token de identidade com garantias criptográficas. Os serviços poderiam então consumir e validar esse token sem precisar lidar com a complexidade de oferecer suporte a várias estratégias de authN. Em outras palavras, uma única autoridade tomaria a decisão de authN e repassaria um JWT assinado para o restante do sistema consumir.

Para isso, precisávamos introduzir uma nova camada no sistema, capaz de autenticar solicitações e gerar o token padronizado. Foi aí que entrou o Gloo Edge, um tipo de API Gateway.

Conectando tudo com o Gloo!

O que são API Gateways?

Não somos especialistas em API Gateways, mas podemos apresentar uma lista básica do que eles podem fazer:

• Validação de solicitações

• Limitação de taxa

• Autenticação (ou podem ser estendidos para isso!)

• E muito, muito mais! (Avisamos que não somos especialistas…)

E aqui vem o melhor: tudo acontece na borda! Se algum dos seus aplicativos faz uma das coisas que mencionamos acima, provavelmente você pode delegar essa tarefa ao seu API Gateway. Assim, você elimina linhas de código — o que todo engenheiro adora fazer! ?

Analisamos várias opções de API Gateways e escolhemos o Gloo Edge (que chamaremos de Gloo neste artigo) para nos ajudar em nossa jornada de plataforma. Esta publicação não vai explicar como nem por que escolhemos o Gloo. Esse assunto fica para uma próxima publicação!

O que é o Gloo Edge?

O Gloo Edge é um API Gateway desenvolvido pela Solo.io. Ele funciona como uma abstração sobre o Envoy e permite usar definições de recursos personalizados (CRDs) do Kubernetes para gerar configurações do Envoy — o que torna a curva de adoção bem baixa. Se você sabe escrever configurações do Kubernetes, provavelmente consegue escrever configurações do Envoy usando os CRDs próprios do Gloo.

Para saber mais sobre o Gloo, o que ele é e como aproveita o Envoy, consulte a documentação do Gloo Edge (que é realmente muito boa)!

Implementando o Gloo Edge na Snyk

Nas próximas seções, vamos detalhar parte do trabalho que fizemos para colocar o Gloo na frente da API e integrá-lo a parcerias realmente interessantes!

Identificando um caminho de migração (se sua API já estiver em uso)

A API da Snyk recebe tráfego constantemente, então simplesmente colocá-la atrás do Gloo não era uma opção. Como mencionamos acima, historicamente a API para clientes usava exclusivamente chaves de API para autenticar solicitações. Mas a mudança para permitir JWTs e chaves de API no API Gateway criou uma divisão entre o antigo e o novo.

Por sorte, o grupo já estava animado para mudar o domínio da nossa API de https://snyk.io/api/ para https://api.snyk.io. Mas não queríamos redirecionar todas as solicitações do DNS original para o novo se fôssemos colocá-lo atrás do novo API Gateway. Em vez disso, estamos fazendo uma implantação canário ponderada, baseada em porcentagem, do API Gateway no domínio antigo da API.

Em outras palavras, atualmente estamos direcionando parte do tráfego do nosso DNS original pelo API Gateway. O restante segue para o monólito, que toma as decisões de authN.

O Gloo oferece suporte à implantação canário pronta para uso. Mas, como ainda não direcionamos todo o tráfego da API pelo Gateway, estamos usando o padrão de mudança de tráfego do Envoy Proxy. Veja a figura abaixo para um exemplo geral de como isso funciona e como poderia ser útil para você.

Transferindo a validação de JWT para a borda

Embora a prova de conceito de OAuth mencionada anteriormente implementasse OAuth, ela era estreitamente acoplada ao nosso hub de identidade (e implementada no monólito). Essa nova biblioteca de authN precisava validar o JWT enviado pelo hub de identidade, o que seria mais ou menos assim:

• Validar o payload do JWT (sub, iat, aud)

• Validar a assinatura do JWT usando endpoints de JWKs (JSON Web Key Sets)

Embora, tecnicamente, esse seja um desafio trivial, normalmente ele exige uma boa quantidade de código (menos de 100 linhas), sem contar os testes. É possível fazer o mesmo adicionando menos de 20 linhas de código à sua VirtualService no Gloo:

1jwtStaged:
2 beforeExtAuth:
3   providers:
4     snyk:
5       issuer: <a valid jwt issuer> # where did the token come from?
6       audiences:
7         - <a valid jwt audience> # what service expects the token?
8       tokenSource:
9         headers: # Regex currently not supported
10           - header: Authorization
11             prefix: "Bearer"
12           - header: Authorization
13             prefix: "bearer"
14       jwks:
15         remote:
16           upstreamRef:
17             name: <upstream name>
18             namespace: <upstream namespace>
19           url: <a valid jwks endpoint>

Essa configuração extrai o JWT do cabeçalho e executa algumas etapas básicas de validação antes de enviar o JWT a um plugin External Auth (ExtAuth) (falaremos mais sobre isso adiante!):

• Verificar se o horário atual está dentro do intervalo definido pelas declarações iat (emitido em) e exp (expiração) do JWT

• Validar o público-alvo

• Validar o emissor

• Validar a assinatura usando um endpoint externo de JWKs (upstream)

Conseguimos transferir muitas validações do monólito para a borda! Legal, né? ??

Unificando estratégias de authN

Mesmo validando JWTs na borda, apenas ajudamos o sistema ao tirar essa tarefa do monólito. Como você deve ter percebido pelo título e pela introdução deste artigo, só validar JWTs na borda não é suficiente. Também queremos transferir as decisões de authN para a borda, permitindo que o Gloo as tome com base no material de chave fornecido pelo usuário.

Para isso, introduzimos um plugin de Autorização Externa (ExtAuth), um tipo exclusivo de plugin criado pelo Gloo (disponível apenas no pacote Enterprise), escrito em Go e compilado como um filtro de Autorização Externa do Envoy. Primeiro, o plugin identifica o tipo de material de chave fornecido pelo usuário e estabelece sua identidade. Depois, assina o token criptograficamente e o envia à API downstream, que valida a assinatura do token e executa a operação solicitada em nome do usuário. A figura abaixo mostra um exemplo simples de como isso poderia funcionar.

Em outras palavras, neste ponto criamos um token interno que pode ser usado por qualquer serviço do nosso cluster, contendo informações do usuário que podem ser associadas a um usuário em nosso banco de dados! Os serviços roteados pelo Gloo verificam se o JWT foi assinado pelo Gloo. Talvez isso não pareça muita coisa, mas antes precisávamos solicitar explicitamente os dados do usuário ao monólito para obter qualquer informação sobre a identidade dele em cada serviço.

Além disso, o Gloo permite que nossos serviços gerenciem um único método de authN, enquanto ele cuida da complexidade de gerenciar várias estratégias de authN na borda.

Tudo isso é feito sem grandes dificuldades e com poucas linhas de código (a maior parte é código boilerplate criado pela Solo), em vez de implementar estratégias de authN específicas em cada serviço. 

Próximos passos

Nos próximos sprints, a equipe de Extensibilidade vai se concentrar em duas áreas relacionadas ao nosso API Gateway:

• Transferir aos poucos todo o tráfego da API para o Gloo (ou seja: implantação canário!).Queremos começar a direcionar pelo API Gateway o tráfego “normal”, que não é específico de parceiros. Para isso, precisamos implementar a observabilidade e os alertas necessários e garantir que os engenheiros de plantão consigam dar suporte à nova infraestrutura. Também será necessário fazer o trabalho complexo de direcionar ao proxy Envoy do Gloo uma porcentagem do tráfego que chega atualmente pelo ponto de entrada da API.

• Ampliar o Gloo para validar solicitações na borda.Atualmente, o Gloo não oferece esse recurso pronto para uso.

Esperamos que esta publicação tenha sido útil se você está pensando em usar o Gloo no seu ambiente! Em futuras publicações, vamos mostrar como o Gloo deu às equipes de Engenharia e Produto uma excelente base de observabilidade e como nos incentivou a aprimorar as práticas de CI/CD na Snyk.

Quer fazer parte de uma equipe de engenharia de ponta? Estamos contratando no mundo todo.