Implantando o Wallarm Sidecar¶

Para proteger uma aplicação implantada como um Pod em um cluster Kubernetes, você pode executar o nó Wallarm baseado em NGINX na frente da aplicação como um controlador sidecar. O controlador sidecar Wallarm filtrará o tráfego de entrada para o Pod de aplicação, permitindo apenas solicitações legítimas e mitigando as maliciosas.

As principais características da solução Wallarm Sidecar incluem:

• Simplifica a proteção de microserviços discretos e suas réplicas e shards, fornecendo o formato de implantação que é semelhante às aplicações

• Totalmente compatível com qualquer controlador Ingress

• Funciona de forma estável sob cargas altas, geralmente comuns para a abordagem de malha de serviço

• Exige configuração mínima do serviço para proteger seus aplicativos; basta adicionar algumas anotações e rótulos ao pod de aplicação para protegê-lo

• Suporta dois modos de implantação do contêiner Wallarm: para cargas médias com os serviços Wallarm rodando em um único contêiner e para cargas altas com os serviços Wallarm divididos em vários contêineres

• Fornece uma entidade dedicada para o módulo pós-analítico, que é o backend local de análise de dados para a solução Wallarm sidecar, consumindo a maior parte da memória

Casos de uso¶

Entre todas as opções de implantação do Wallarm suportadas, esta solução é recomendada para os seguintes casos de uso:

• Você está procurando a solução de segurança a ser implantada na infraestrutura com o controlador Ingress existente (por exemplo, AWS ALB Ingress Controller) impedindo você de implantar o Controlador Ingress baseado em Wallarm NGINX ou o Controlador Ingress baseado em Wallarm Kong

• Ambiente de confiança zero que exige que cada microserviço (incluindo APIs internas) seja protegido pela solução de segurança

Fluxo de tráfego¶

Fluxo de tráfego com Wallarm Sidecar:

Arquitetura da solução¶

A solução Wallarm Sidecar é organizada pelos seguintes objetos de implantação:

• Controlador Sidecar (wallarm-sidecar-controller) é o webhook de admissão mutante que injeta recursos do Wallarm sidecar no Pod, configurando-o com base nos valores do gráfico Helm e anotações do pod e conectando os componentes do nó ao Wallarm Cloud.

  Uma vez que um novo pod com o rótulo wallarm-sidecar: enabled no Kubernetes começa, o controlador injeta automaticamente o contêiner adicional filtrando o tráfego de entrada no pod.

• Módulo pós-analítico (wallarm-sidecar-postanalytics) é o backend local de análise de dados para a solução Wallarm sidecar. O módulo utiliza o armazenamento em memória Tarantool e um conjunto de alguns contêineres auxiliares (como o collectd, serviços de exportação de ataque).

O Wallarm Sidecar tem 2 estágios padrão em seu ciclo de vida:

1. No estágio inicial, o controlador injeta recursos do Wallarm sidecar no Pod, configurando-o com base nos valores do gráfico Helm e anotações do pod e conectando os componentes do nó ao Wallarm Cloud.

2. No estágio de tempo de execução, a solução analisa e encaminha/repassa solicitações envolvendo o módulo pós-analítico.

Requisitos¶

• Versão da plataforma Kubernetes 1.19-1.25

• Gerenciador de pacotes Helm v3

• Uma aplicação implantada como um Pod em um cluster Kubernetes

• Acesso a https://us1.api.wallarm.com para trabalhar com o Wallarm Cloud US ou a https://api.wallarm.com para trabalhar com o Wallarm Cloud EU

• Acesso a https://charts.wallarm.com para adicionar os gráficos Helm do Wallarm

• Acesso aos repositórios Wallarm no Docker Hub https://hub.docker.com/r/wallarm

• Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers

  US CloudEU Cloud

  34.96.64.17
  34.110.183.149
  35.235.66.155
  34.102.90.100
  34.94.156.115
  35.235.115.105
  

  34.160.38.183
  34.144.227.90
  34.90.110.226
  

• Acesso à conta com a função de Administrador no Console Wallarm para o Cloud US ou o Cloud EU

Implantação¶

Para implantar a solução Wallarm Sidecar:

1. Gere um token de nó de filtragem.

2. Implantar o gráfico Helm Wallarm.

3. Anexe o Wallarm Sidecar ao Pod de aplicação.

4. Teste a operação Wallarm Sidecar.

Passo 1: Gere um token de nó de filtragem¶

Gere um token de nó de filtragem do tipo apropriado para conectar os pods do sidecar à Wallarm Cloud:

Passo 2: Implementar o gráfico Helm Wallarm¶

1. Adicione o repositório gráfico Wallarm:
   

   helm repo add wallarm https://charts.wallarm.com
   

2. Crie o arquivo values.yaml com a configuração Wallarm Sidecar. Exemplo do arquivo com a configuração mínima está abaixo.

   Ao usar um token API, especifique um nome de grupo de nó no parâmetro nodeGroup. Seus nós criados para os pods do sidecar serão atribuídos a este grupo, mostrado na seção Nós do Console Wallarm. O nome do grupo padrão é defaultSidecarGroup. Se necessário, você pode definir os nomes dos grupos de nós de filtragem individualmente para os pods das aplicações que eles protegem, usando a anotação sidecar.wallarm.io/wallarm-node-group.

   Nuvem EUANuvem UE

   config:
     wallarm:
       api:
         token: "<NODE_TOKEN>"
         host: "us1.api.wallarm.com"
         # nodeGroup: "defaultSidecarGroup"
   

   config:
     wallarm:
       api:
         token: "<NODE_TOKEN>"
         # nodeGroup: "defaultSidecarGroup"
   

   <NODE_TOKEN> é o token do nó Wallarm a ser executado no Kubernetes.

   Usando um token para várias instalações

   Você pode usar um token em várias instalações, independentemente da plataforma selecionada. Isso permite o agrupamento lógico de instâncias de nó na interface de usuário do Wallarm Console. Exemplo: você implanta vários nós Wallarm em um ambiente de desenvolvimento, cada nó está em sua própria máquina de propriedade de um determinado desenvolvedor.

3. Implante o gráfico Helm Wallarm:

   helm install --version 4.8.0 <RELEASE_NAME> wallarm/wallarm-sidecar --wait -n wallarm-sidecar --create-namespace -f <PATH_TO_VALUES>
   

   • <RELEASE_NAME> é o nome para o lançamento Helm do gráfico Wallarm Sidecar
   • wallarm-sidecar é o novo namespace para implantar o lançamento Helm com o gráfico Wallarm Sidecar, é recomendado implantá-lo em um namespace separado
   • <PATH_TO_VALUES> é o caminho para o arquivo values.yaml

Passo 3: Anexe o Wallarm Sidecar ao Pod de aplicação¶

Para que o Wallarm filtre o tráfego da aplicação, adicione o rótulo wallarm-sidecar: enabled ao Pod de aplicação correspondente:

kubectl edit deployment -n <APPLICATION_NAMESPACE> <APP_LABEL_VALUE>

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
        wallarm-sidecar: enabled
    spec:
      containers:
        - name: application
          image: kennethreitz/httpbin
          ports:
            - name: http
              containerPort: 80

• Se o rótulo do Pod de aplicação wallarm-sidecar estiver definido como disabled ou não for especificado explicitamente, o contêiner Wallarm Sidecar não é injetado em um pod e, portanto, o Wallarm não filtra o tráfego.

• Se o rótulo do Pod de aplicação wallarm-sidecar estiver definido como enabled, o contêiner Wallarm Sidecar é injetado em um pod e, portanto, o Wallarm filtra o tráfego de entrada.

Passo 4: Teste a operação Wallarm Sidecar¶

Para testar se o Wallarm Sidecar opera corretamente:

1. Obtenha os detalhes do pod Wallarm para verificar se eles foram iniciados com sucesso:

   kubectl get pods -n wallarm-sidecar -l app.kubernetes.io/name=wallarm-sidecar
   

   Cada pod deve exibir o seguinte: READY: N/N e STATUS: Running, por exemplo:

   NAME                                              READY   STATUS    RESTARTS   AGE
   wallarm-sidecar-controller-54cf88b989-gp2vg       1/1     Running   0          91m
   wallarm-sidecar-postanalytics-86d9d4b6cd-hpd5k   4/4     Running   0          91m
   

2. Obtenha os detalhes do pod de aplicação para verificar que o controlador Wallarm sidecar foi injetado com sucesso:

   kubectl get pods -n <APPLICATION_NAMESPACE> --selector app=<APP_LABEL_VALUE>
   

   A saída deve exibir READY: 2/2 indicando a bem-sucedida injeção do contêiner sidecar e STATUS: Running indicando a bem-sucedida conexão com o Wallarm Cloud:

   NAME                     READY   STATUS    RESTARTS   AGE
   myapp-5c48c97b66-lzkwf   2/2     Running   0          3h4m
   

3. Envie o ataque de teste Path Traversal para o endereço do cluster da aplicação que o Wallarm está habilitado para filtrar o tráfego:

   curl http://<APPLICATION_CLUSTER_IP>/etc/passwd
   

   Como o proxy Wallarm opera no modo de filtração monitoramento por padrão, o nó Wallarm não bloqueará o ataque, mas o registrará.

   Para verificar se o ataque foi registrado, acesse Wallarm Console → Eventos:

   

Personalização¶

Pods Wallarm foram injetados com base no values.yaml padrão e na configuração personalizada que você especificou no 2º passo de implantação.

Você pode personalizar ainda mais o comportamento do proxy Wallarm em níveis globais e por pod e tirar o máximo proveito da solução Wallarm para sua empresa.

Basta ir para o guia de personalização da solução proxy Wallarm.

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send