5 Passos para Integração do Istio com OPA

Autenticação e Autorização são grandes partes do puzzle de segurança que precisa ser resolvido por arquitetos de nuvem e engenheiros DevOps. Neste blog, vamos olhar especificamente em como alcançar autorização/controle de acesso; ou seja, quais ações a entidade autenticada pode executar na mesh de serviços Istio. Isso ajuda a segurar a infraestrutura impedindo ações com intenções maliciosas.

A autorização em uma mesh de serviços pode ser definida usando políticas OPA. OPA é um mecanismo que ajuda os funcionários DevOps a definir e aplicar políticas de autorização para cargas de trabalho do Kubernetes. Neste texto, vamos ver:

• O que é a OPA
• Por que você deve integrar a OPA com a mesh de serviços Istio
• Como o Istio e a OPA autorizam solicitações
• As etapas exatas que você pode seguir para integrar a OPA com o Istio

O que é a OPA?

OPA (abreviação de “Open Policy Agent”) é um agente de aplicação de políticas de código aberto, de propósito geral, que permite que os funcionários DevOps definem as políticas de código usando uma linguagem de declaração de alto nível chamada Rego. A OPA ajuda a definir e aplicar de forma centralizada as políticas em toda a stack,解放ando os desenvolvedores de escrever políticas de autorização no código do aplicativo. Aqui é como a OPA funciona (referir-se ao Figure 1):

1. O aplicativo/serviço recebe uma solicitação.
2. O serviço envia uma solicitação de autorização em JSON para a OPA.
3. A OPA verifica a solicitação contra as políticas de autorização definidas.
4. A OPA toma a decisão e retorna a resposta de autorização (ALLOW/DENY) para o serviço no formato JSON.

Figura 1: Fluxo de solicitação de autorização com OPA

Observe que não é preciso que seja uma aplicação escrita por um desenvolvedor que está enviando a solicitação de autorização: pode ser o Argo CD, o recurso da API do Gateway do Kubernetes, o Terraform, o Prometheus ou qualquer coisa else, pois o OPA é de propósito geral. (Mencionei e desenhei uma aplicação em um cluster Kubernetes aqui por questões de conveniência e melhor compreensão.)

Por que integrar o OPA com o Istio?

O Istio tem um mecanismo de autorização robusto. No entanto, ter um motor de aplicação de políticas dedicado como o OPA junto ao mesh de serviços do Istio tem suas próprias vantagens:

• Sistema de gerenciamento centralizado para definir e aplicar políticas: O OPA torna mais fácil para os DevOps gerenciar centralmente as políticas de autorização para toda a stack. Isso inclui cargas de trabalho em mesh, stack não-mesh e também verificações de autorização (uma política que impede o deploy no final de semana, por exemplo). 
• Mais flexibilidade e granularidade na definição de políticas: Se você olhar para a tabela abaixo (Figura 2), é claro que a autorização do Istio pode fazer muito e corresponder a uma solicitação com base em uma variedade de campos de diferentes fontes de dados. No entanto, a CRD de AuthorizationPolicy do Istio pode ter limitações em configurar o corpo da solicitação HTTP ou qualquer dado contextual nos campos, para os quais o OPA pode ser usado. Ao contrário do Istio, o OPA pode usar qualquer dado para avaliação de política.
• Configuração simplificada de AuthZ: Pode ser cansativo para os DevOps configurar regras de autorização complexas no Istio. O OPA é configurado usando o Rego, que é mais parecido com uma linguagem de programação. É relativamente fácil definir regras de política básicas a complexas usando o Rego.

Figura 2: Comparação tabular entre autorização do Istio e do OPA (fonte)

Como o Istio e o OPA autorizam solicitações

Os DevOps podem implantar o OPA como um serviço separado ou como um container sidecar juntamente com o proxy Envoy e o container da aplicação em um pod. A abordagem de container sidecar é melhor para reduzir o latência.

Os containers sidecar do OPA precisam ser injetados no pod da aplicação, tal como os containers sidecar do proxy Envoy do Istio. Podemos configurar os containers OPA injetados para montar ConfigMaps que contêm as regras de autorização; então, cada container sidecar OPA no namespace montará a mesma configuração e regras AuthZ definidas no ConfigMap.

Uma vez que o sidecar OPA for injetado, o proxy Envoy envia solicitações de autorização para o OPA para tomar decisões de autorização quando o serviço recebe uma solicitação:

Figura 3: Fluxo de trabalho de autorização Istio-OPA

Suppose que as pessoas da equipe DevOps não querem que cada container OPA injetado no mesmo namespace siga as mesmas configurações e queira enforcar regras diferentes. Nesse caso, eles terão que fazer qualquer das seguintes coisas:

• Remover o hard coding que permite que a política de injeção atual use um ConfigMap particular
• Configurar o webhook mutando e desabilitar a injeção sidecar no nível do pod.
• Servir conjuntos de políticas de um servidor HTTP remoto
• Implantação da aplicação e dos sidecars em um namespace diferente com um ConfigMap diferente

Passos Para Integrar O Opa Com O Istio: Demonstração

A ideia aqui é tornar o OPA o autorizador externo em vez dos sidecars do proxy Envoy – para tomar decisões de controle de acesso.

Eu usarei a clássica aplicação Bookinfo da documentação do Istio para a demonstração. Eu configurarei o OPA com o Istio para o controle de acesso e verifiquei se é obrigatório disparando solicitações para bookinfo/productpage:

Figura 4: Diagrama de integração Istio-OPA tutorial

Observe que /productpage é a UI, que faz chamadas internas a outros serviços, como os serviços de avaliações e comentários (diagram). Eu injetarei o OPA em cada pod no namespace bookinfo; todos os containers OPA montam o mesmo ConfigMap e têm as mesmas políticas de autorização por causa disso. O comportamento padrão da aplicação Bookinfo não encaminha nenhuma autenticação HTTP, portanto as chamadas internas falharão na autenticação e, portanto, na autorização.

Nós seguiremos os passos dados na ordem:

1. Configurar injeção de sidecar OPA
2. Permitir comunicação entre o proxy do Istio e o OPA
3. Deploy OPA configuration
4. Aplicar configuração do Istio
5. Deploy the application and test the Istio-OPA authorization setup

O pré-requisito para a demonstração é ter o Istio v1.19+ instalado no seu cluster. Aqui estou usando o Istio v1.21.0.

OPA fornece um quickstart.yaml para instalação fácil. Eu dividi o yaml em três para melhor entendimento: IMESH GitHub repo. 

Step 1: Configure OPA Sidecar Injection

Aplicar o opa_controller.yaml:

kubectl apply -f opa_controller.yaml

O opa_controller.yaml implanta tudo – certificados TLS, ConfigMap que contém a política de injeção, implantação do controlador de admissão e configuração do webhook mutante – no namespace opa-istio (consulte o quadro 5):

1. O controlador de webhook mutante (opa-istio-admission-controller) então escutará por uma etiqueta particular (opa-istio-injection) com o valor definido como habilitado.
2. O controlador de webhook chama o admission-controller, que tem a política de injeção.
3. A política de injeção diz ao admission-controller como injetar o container sidecar OPA no pod.

Figura 5: Configuração de injeção de sidecar OPA

Agora, antes de deployar o aplicativo Bookinfo, vamos criar o namespace bookinfo e seguir as outras etapas:

Crie o namespace bookinfo aplicando bookinfo-ns.yaml:

kubectl apply -f bookinfo-ns.yaml

Passo 2: Habilitar a Comunicação Entre o Proxy Istio e OPA

Edite o ConfigMap Istio no namespace istio-system e adicione extensionProviders (opa-ext-authz-grpc), para que ele habilite a autorização externa na mesh:

• Copie extensionProviders das observações em opa_controller.yaml.
• Edite o ConfigMap Istio e adicione extensionProviders no campo da mesh.
• Certifique-se que a indentação esteja correta.
• Salve a configuração.

A etapa torna possível que o istio-proxy converse com o container opa-istio no pod para pedidos de autorização.

Se você olhar para o extensionProviders, ele é um filtro de tipo ExtAuthzGrpc em Envoy com um serviço entrada e porta especificados:

...

extensionProviders:
- name: opa-ext-authz-grpc
envoyExtAuthzGrpc:
service: opa-ext-authz-grpc.local
       port: "9191"

...

O nome, endereço de serviço e porta dos extensionProviders devem ser os mesmos no opa_authz.yaml e opa_config.yaml.

Passo 3: Implementar Configuração do OPA

O opa_config.yaml define configurações relacionadas à política aberta. Ele tem opa-istio-config e opa-policy ConfigMaps — que definem a implementação do serviço gRPC (envoy_ext_authz_grpc) e as políticas de autorização reais, respectivamente.

As políticas de autorização podem ser divididas em duas partes: a primeira parte define as condições sob as quais a autorização é permitida ou negada; a segunda parte define os papéis do usuário e as permissões para cada papel.

As políticas de autorização podem levar algum tempo para se ajustar, pois o Rego não usa muitas palavras-chaves aqui. Habilite uma versão mais recente do Rego para obter palavras-chave (palavra-chave allow if condition, por exemplo).

Aplique a configuração do OPA no namespace bookinfo, já que ela faz parte da aplicação:

kubectl apply -f opa_config.yaml -n bookinfo

Passo 4: Aplicar Configuração do Istio

O arquivo opa_authz.yaml contém configurações do Istio. Tem uma AuthorizationPolicy e um ServiceEntry. Observe que o fornecedor da Política de Autorização é opa-ext-authz-grpc, que é o extensionProvider que configuramos no ConfigMap no passo 2.

Similarmente, o hostname definido no ServiceEntry é o mesmo que o endereço de serviço fornecido no extensionProvider (opa-ext-authz-grpc.local). O serviço gRPC irá executar na porta 9191 no localhost 127.0.0.1, que o ServiceEntry faz com que os sidecars do opa-istio sejam acessíveis dentro do pod pelo container istio-proxy.

Implemente a configuração:

kubectl apply -f opa_authz.yaml -n bookinfo

Passo 5: Implemente o Aplicativo e Teste a Configuração de Autorização Istio-OPA

Implemente o aplicativo Bookinfo e o gateway:

kubectl apply -f /your_Istio_directory/samples/bookinfo/platform/kube/bookinfo.yaml -n bookinfo
kubectl apply -f /your_Istio_directory/samples/bookinfo/networking/bookinfo-gateway.yaml -n bookinfo

Verifique os pods no namespace bookinfo:

kubectl get pods -n bookinfo

Você pode ver que cada pod tem 3 containers executando em seu interior: o aplicativo, o proxy Envoy (istio-proxy) e o OPA (opa-istio) containers.

Obtenha o IP do gateway Istio para acessar o serviço:

kubectl get svc -n istio-system

Agora tudo está pronto, e estamos prontos para testar as políticas de autorização. As políticas que definimos em opa_config.yaml são as seguintes:

...

user_roles = {
"alice": ["guest"],
"bob": ["admin"]
}

role_perms = {
"guest": [
{"method": "GET", "path": "/productpage"},
],
"admin": [
{"method": "GET", "path": "/productpage"},
{"method": "GET", "path": "/api/v1/products"},
        ],

...

Alice é um usuário convidado que só pode acessar o /productpage; Bob é um admin que pode acessar os caminhos /productpage e /api/v1/products. Vamos verificar as políticas.

Tentando acessar /api/v1/products de Alice:

curl -vvv your_istio_gateway_ip/api/v1/products -u alice:password

Você pode ver que a resposta 403 Proibido desde que Alice não tem acesso à pasta. Vamos tentar o mesmo caminho como Bob:

curl -vvv your_istio_gateway_ip/api/v1/products -u bob:password

Ele mostra o estado HTTP 200 OK e o conteúdo da página no final da resposta.

Cenário de exemplo para controle de acesso com OPA

Você pode usar a POLítica de Autorização do Istio para enforcar a política mostrada no demo acima. Você não precisa do OPA. No entanto, há situações em que o controle de acesso do Istio pode ser limitado, conforme mencionado na tabela no início. Deixe-me dar um exemplo simples.

Suponha que existe uma aplicação de BookReviews, que é um serviço GraphQL, onde os revisores enviam resenhas, editores editam e publicam essas resenhas, e usuários lidam com as resenhas publicadas.

Quando um revisor adiciona uma resenha ao serviço, a solicitação incluiria o JWT do revisor, contendo os grupos e papéis (revisor ou editor) aos quais o revisor pertence. O corpo da solicitação também conteria a consulta de mutação GraphQL com os dados da resenha recém-criada.

Vamos dizer que você quer garantir as seguintes condições:

• Somente revisores podem enviar resenhas.
• Um editor só pode editar uma resenha se ela for escrita por um revisor que pertence ao mesmo grupo gerenciado por ele.
• Somente editores podem marcar uma resenha como “pronta para publicação”.

Este é o diagrama que inclui as políticas acima:

A POLítica de Autorização do Istio terá dificuldade em enforcar as condições acima. A razão é que o Istio não pode usar o corpo da solicitação GraphQL para verificações de autorização, que é um objeto JSON junto do JWT necessário para a avaliação da política.

OPA não tem essas limitações. Ele pode carregar qualquer dado para verificação de políticas e DevOps pode escrever essas regras de uma maneira mais ergonômica usando o Rego.

Vídeo: demonstração em ação

Se você preferir assistir à demonstração em ação, por favor verifique o vídeo abaixo:S

Suporte Empresarial para Integração do Istio

A maioria das empresas usa o OPA para definir e aplicar políticas de autorização para toda sua pilha. Ter um mecanismo central de controle de acesso melhora a segurança e a agilidade dos times de TI. Caso contrário, os desenvolvedores gastarão tempo desenvolvendo políticas de autorização em seu código de aplicação escrito em uma linguagem particular, o que impede a escalabilidade e o lançamento mais rápido da lógica de negócios.