Introdução

Na indústria sempre discutimos qual será a próxima tecnologia, produto e empresa que irá quebrar todos os paradigmas e fornecer a solução para a nova revolução digital tão necessária para a evolução dos negócios.

A arquitetura de microsserviços hoje é o assunto que tem movimentado a indústria de TI. Essa sensação de renovação já foi sentida no passado com empresas .com, e-commerce, redes sociais, grid computing entre outras. Entretanto, a grande diferença entre microsserviços e outras tecnologias e arquiteturas é a importância estratégica que ela representa para as empresas.

Em termos simples, microsserviços cria uma estrutura digital bem organizada das capacidades de negócio e expõe essas mesmas capacidades através de APIs. Cedo ou tarde essas APIs se tornam o principal meio de colaboração digital para toda corporação, demais sistemas de TI, desenvolvedores, comunidade, parceiros de negócio e outras partes interessadas.

Microsserviços também impulsiona e recebe influência de DevSecOps, uso de containers, Arquiteturas nativas de Cloud (Cloud Native) e computação nas Nuvens.

Siga na leitura e saiba mais sobre a função estratégica da arquitetura de microsserviços.

Segurança

Em recente pesquisa realizada pelo Gartner com 3000 CIOs , uma das grandes preocupações mencionadas foi a cybersegurança.  Como lidar com tantas ameaças virtuais tais como cyberterrorismo, virus de computador, ataques de phishing, ataques de negação de serviço e outros em um ambiente tão complexo de aplicações cada vez mais expostas ao consumidor final? Além disso, como atender às expectativas de tantas partes interessadas em uma plataforma que permita a inovação e que atenda à tantos requisitos de compliance e políticas corporativas?

Nos próximos tópicos abordaremos as soluções possíveis para fazer frente a todas essas questões.

IAAA Framework

Nesse momento, o papel da arquitetura de soluções se faz essencial ao oferecer ferramentas e técnicas capaz de ajudar as empresas a entenderem o contexto de segurança em que estão inseridas. O Framework IAAA aborda o assunto cybersegurança a partir de 4 grandes pilares:

• Identification: como controlar e estabelecer as identidades que fazem parte do ecossistema de TI: usuários, serviços, domínios, componentes do sistema etc;
• Authentication: que métodos de validação de credenciais fornecidos pelas identidades devem ser suportados;
• Authorization: uma vez que uma identidade seja válida, que permissões e privilégios ela pode obter ou delegar na corporação;
• Accountability: como capturar as informações relevantes e eventos de segurança. Ações relevantes vão desde uma simples autenticação, passando pela auditoria à todos os acessos à cada um dos sistemas até um eventual ataque de intrusos vindos do outro lado do planeta.

Arquitetura Estruturante

Sabemos que criar aplicações aderentes aos requisitos do padrão arquitetural microsserviços demandam uma série de fatores fundamentais para estruturação da arquitetura.

O kubernetes é uma plataforma de execução de contêineres que concentra uma série de características importantes:

• Bons mecanismos relevantes para execução de aplicações ex: service discovery, escalabilidade, resiliência, etc.
• Alta taxa de adoção
• Extensível
• Em evolução
• Portabilidade
• Declarativo
• Clusterizado
• Adaptável a vários tipo de nuvens (cloud pública ou ambiente on premise)
• Escalável

Uma aplicação de porte médio pode levar facilmente à criação de vários microsserviços. Logo imaginamos que se não forem estabelecidos bons mecanismos de controle e governança, rapidamente o caos se instala e surge o que é chamado de “arquitetura spaghetti” onde não existe controle do fluxo da informação. Nesse ambiente desestruturado é muito fácil que usuários maliciosos ou invasores externos obtenham informações e causem prejuízos.

É necessário que o arquiteto de soluções complemente o Kubernetes com uma aplicação que cuide do entrelaçamento dos serviços: Service Mesh.

Service Mesh

O Service Mesh organiza, mantém, controla e enriquece a comunicação entre microsserviços. Existem vários tipos de service mesh mas estamos interessados na implementação que possui a maior quantidade de recursos para estabelecermos nossa arquitetura de segurança. Seu nome é Istio.

Com relação ao fluxo de dados, a comunicação “lateral” isto é, interna ao ambiente (ou domínio) é chamada de fluxo leste-oeste. Quando uma requisição vem de fora provocada por um agente externo (ingress), chamamos de fluxo norte-sul. Todo fluxo de dados que sai do domínio é chamado de egress. O Istio tem papel fundamental da implementação de segurança no perímetro interno e na comunicação com entidades externas.

*Fonte da imagem: Istio.io

O Istio controla o fluxo de entrada no domínio através de seu componente Ingress Controller. Em contrapartida, o fluxo de saída está sob a tutela do Egress Controller.

O operador ou administrador do service mesh interage com o Istio através de componentes administrativos chamados de control plane (plano de controle). As regras, configurações e políticas criadas pelos administradores são aplicados ao fluxo de dados entre microsserviços. Esse fluxo é chamado data plane (plano de dados).

Arquitetura do Istio

 Todo esse controle de dados só é possível porque cada microsserviço ganha do control plane do Istio um servidor proxy muito rápido (envoy) que intercepta toda comunicação de entrada e saída. Esse proxy é configurado automaticamente quando uma aplicação é instalada no kubernetes e através dele é possível por exemplo a troca de dados através de conexão segura (mTLS ou mutual TLS), validação de políticas, telemetria, controle de vazão, injeção de erros e auditoria.

Os componentes do Istio são:

• Pilot: é o elemento principal do control plane. É o responsável por configurar cada proxy que faz parte do mesh e aplicar informações de roteamento e políticas;
• Citadel: gerá certificados para estabelecer a conexão mtls entre os microsserviços;
• Mixer: Responsável pela telemetria e gerenciamento de autorização e auditoria.

OIDC e OAUTH2

OIDC (ou openid connect) é um protocolo de autenticação construído sobre outro protocolo de autorização chamado Oauth 2.0. Esses 2 protocolos já foram amplamente estudados e são aplicáveis em diversos tipos de cenários de autenticação e autorização porque suportam fluxos (flow) diferentes exemplo: se o usuário final está interagindo com uma API ou com uma aplicação web, fluxos diferentes são usados.

Alguns pontos importantes:

• O resultado de uma autenticação de sucesso no OIDC resulta em algo chamado IDTOKEN. O Id token é normalmente um token no formato JWT que contém a Identidade do usuário;
• Um IDTOKEN é utilizado para se obter o token de autorização que dá permissões a uma identidade interagir com um ou mais serviços. Esse token de autorização é chamado AccessToken;
• O Identity Provider é a entidade central que valida as credenciais apresentadas pelo usuário final (username e senha por exemplo) e credenciais apresentadas pelos serviços (client id e client secret). Assim, temos 2 identidades estabelecidas e podemos confiar que os participantes do fluxo não foram comprometidos.

O OIDC é bem aplicável quando se deseja estabelecer a identidade de agentes externos (usuários) no fluxo norte-sul,  a fim de que possam interagir com as aplicações internas ao domínio.

Nota: É usual o uso de servidores de identidade para geração e validação de tokens de aplicação e usuários. Esses servidores podem ser externos, de terceiros e não precisam necessariamente estar instalado no kubernetes. O importante é que devem ser acessados de forma segura (TLS) e devem ser escaláveis.

Token Exchange

Como parte do protocolo Oauth2, foi criado um novo protocolo de define regras para obtenção de tokens de acesso a partir servidores de autorização Oauth2 no cenário onde múltiplas audiências (isto é, múltiplos microsserviços) estão envolvidas no mesmo fluxo de chamada. Nesse cenário, um token de acesso obtido para um serviço inicial (serviço A) não deveria ser repassado para um serviço qualquer (serviço B) simplesmente porque tokens são gerados para audiências (serviços) específicos.

O problema desse modelo é que o processo de exchange depende dessa entidade central que é o servidor de identidades, causando problemas de latência, escalabilidade e ponto central de falha. Outro problema é que a propagação de tokens depende de detalhes de implementação das aplicações e até o momento que este artigo foi escrito mecanismos para propagação automática ou exchange de token ainda estavam sendo discutidos.

Policy Enforcement com OPA

O uso do proxy envoy para interceptação do fluxo de dados se mostra uma grande vantagem para a arquitetura do service mesh pois sua arquitetura é extremamente plugável. Para a arquitetura de segurança, isso é relevante já que conseguimos “plugar” mecanismos e ferramentas que validem e inspecionem em tempo real, o fluxo de entrada e saída de cada microsserviço.

Uma dessas ferramentas é o open policy agent (OPA) que é utilizado para aplicar políticas customizadas que podem impedir que entidades não conformantes tenham qualquer ação no domínio de aplicações.

OPA – Open policy Agent

O Open policy agent é um projeto incubado do CNCF (cloud native computing foundation) para criação de política como código. Seus objetivos são:

• Unificada: desacoplar políticas de serviços permite que o controle sejá unificado e estendido para todo o domínio independentemente da linguagem ou algum framework específico;
• Declarativo: permitir a políticas sejam expressas em uma linguagem declarativa de alto nível que promova a flexibilidade, expressividade, segurança e alta-performance. políticas são descritas em uma linguagem própria chamada REGO. Esse código pode ser testado e validado muito antes de ser aplicado ao ambiente;
• Contextualizada: administradores podem descrever políticas de acordo com o contexto de execução atual, ambiente, parâmetros de requisições etc.

Plugin para istio

O plugin OPA-Istio é um servidor gRPC que implementa a API de autorização do Envoy. Esse servidor se conecta à todas as requisições dos microsserviços e pode ser utilizado para executar políticas com uma granularidade muito pequena, sem a necessidade de modificar o microsserviço.

Ele funciona da seguinte forma: em adição ao container sidecar do Envoy, um novo container é adicionado contendo o OPA. Quando o proxy envoy recebe uma requisição de API destinada a um microsserviço, ela é verificada pelo OPA que decide se essa requisição pode ser atendida ou não.

A execução local de políticas na camada de proxy é preferível porque evita a chamada a uma chamada de rede a entidade central apenas para checagem de autorização. Essa solução é mais performática e escalável do que utilizar um API Gateway ou servidor de políticas central.

Um exemplo comum dessa política é validar tokens IDTOKEN ou AccessToken, permitindo que usuários acessem serviços específicos.

SPIFFE

SPIFFE (secure production identity framework for everyone) fornece uma identidade segura, na forma de certificados X509 para todo workload em um ambiente moderno de produção. SPIFFE remove a necessidade de autenticação em nível de aplicação e a configuração de ACLs complexas (access control list).

Dessa forma, se cada serviço tem sua própria identidade, não existe mais a necessidade de apresentação de client ids e client secrets entre membros de um domínio pois cada serviço conhece e confia em que o está chamando.

Um fato interessante do SPIFFE é que ele pode ser utilizado para garantir a identidade entre múltiplos domínios diferentes, clusteres diferentes, clouds diferentes e assim por diante.  No contexto de autorização, podemos criar políticas em OPA que validem regras de que identidade pode acessar qual serviço.

Kubernetes Enforcement

A plataforma do kubernetes possui excelentes mecanismos de extensibilidade. Esses mecanismos permitem que criemos controles e ações sobre todos os workloads em execução no cluster, mesmo antes deles serem instalados. O OPA pode ser utilizado para a implementação de políticas que forcem os microsserviços a obedeceram regras específicas de funcionamento e padrão na plataforma kubernetes. Alguns exemplos de políticas:

• Como garantir que todas as imagens de containeres vieram de um repositório específico;
• Como auditar que componentes não seguem boas práticas de arquitetura de segurança.

O OPA Gatekeeper é um controlador de admissão (executado quando um novo recurso é criado ou atualizado no kubernetes) que aplica políticas escritas em REGO aos recursos do kubernetes e tem como principais funções:

• Impedir que recursos não compatíveis com políticas sejam criados no cluster;
• Auditar que recursos do cluster infringem as políticas definidas.

Essas políticas são criadas e mantidas como recursos dentro do próprio kubernetes e podem ser disponibilizadas nos ambientes utilizando pipelines de Integração contínua e Entrega contínua.

Neste artigo abordamos de modo detalhado o funcionamento da arquitetura de microsserviços e sua importância estratégica para as organizações. Se desejar mais detalhes sobre o tema, fale conosco. 

** Conteúdo elaborado pelo profissional Leonardo Gonçalves, apoio no time de arquitetura do Grupo Mult.