Requisitos do Sistema

Requisitos do Sistema

Componente Número de Instâncias vCPU Recomendado Memória Mínima Notes

Controlador

mín. 1
3 para HA (número ímpar apenas)

1

1GB

O núcleo de vCPU pode ser compartilhado

Enforcer

1 por nó/VM

1+

1GB

Um ou mais vCPUs dedicados para maior largura de banda de rede no modo Protect

Scanner

mín. 1
2+ para HA/Desempenho

1

1GB

O núcleo da CPU pode ser compartilhado para cargas de trabalho padrão.
Dedique 1 ou mais vCPUs para varredura de imagens em alto volume (10k+).
A varredura de imagens do registro é realizada pelo scanner e gerenciada pelo controlador, e a imagem é baixada pelo scanner e expandida na memória.
A recomendação de memória mínima assume que as imagens a serem escaneadas não são maiores que 0,5 GB.
Ao escanear imagens maiores que 1GB, a memória do scanner deve ser calculada levando em conta o maior tamanho de imagem e adicionando 0,5 GB.
Exemplo - maior tamanho de imagem = 1,3 GB, a memória do contêiner do scanner deve ser 1,8 GB

Gerente

min 1
2+ para HA

1

1GB

vCPU pode ser compartilhado

Plataformas suportadas

  • Distribuições Linux oficialmente suportadas: SUSE Linux, Ubuntu, CentOS/Red Hat (RHEL), Debian, CoreOS, AWS Bottlerocket e Photon.

  • Arquitetura AMD64 e família de arquiteturas ARM

  • CoreOS é suportado (novembro de 2023) para varredura de CVE através da tabela de mapeamento RHEL fornecida pela RedHat. Uma vez que um feed oficial seja publicado pela RedHat para CoreOS, ele será suportado.

  • Sistemas de gerenciamento de contêineres compatíveis com Kubernetes e Docker oficialmente suportados. As seguintes plataformas são testadas com cada lançamento de SUSE® Security: Kubernetes 1.19-1.32, SUSE Rancher (RKE, RKE2, K3s etc), RedHat OpenShift 4.6-4.16 (3.x a 4.12 suportados antes de SUSE® Security 5.2.x), Google GKE, Amazon EKS, Microsoft Azure AKS, IBM IKS, docker nativo, docker swarm. As seguintes plataformas compatíveis com Kubernetes e docker são suportadas e foram verificadas para funcionar com SUSE® Security: VMware Photon e Tanzu, SUSE CaaS, Oracle OKE, Mirantis Kubernetes Engine, Nutanix Kubernetes Engine, docker UCP/DataCenter, docker Cloud.

  • Versão do tempo de execução do Docker: 1.9.0 e superior; versão da API do Docker: 1.21, CE e EE.

  • Tempo de execução Containerd e CRI-O (requer alterações nos caminhos de volume nos yamls de exemplo). Veja as alterações necessárias para Containerd na seção de implantação do Kubernetes e CRI-O na seção de implantação do OpenShift.

  • SUSE® Security é compatível com a maioria dos CNIs suportados comercialmente. Os que foram oficialmente testados e suportados são openshift ovs (sub-rede/multitenant), calico, flannel, cilium, antrea e nuvem pública (gke, aks, iks, eks). O suporte para Multus foi adicionado na v5.4.0.

  • Console: Navegador Chrome ou Firefox recomendado. IE 11 não é suportado devido a problemas de desempenho.

  • Minikube é suportado para uma avaliação inicial simples, mas não para uma prova de conceito completa. Veja abaixo as alterações necessárias para o yaml Allinone rodar no Minikube.

Nota do AWS Bottlerocket: É necessário alterar o caminho do socket do containerd específico para Bottlerocket. Por favor, veja a seção de implantação do Kubernetes para mais detalhes.

Não suportado

  • GKE Autopilot.

  • AWS ECS não é mais suportado. (NOTA: Nenhuma funcionalidade foi removida ativamente para operar SUSE® Security em implantações ECS. No entanto, os testes no ECS não estão mais sendo realizados pela SUSE. Embora proteger cargas de trabalho do ECS com SUSE® Security provavelmente funcione como esperado, problemas não serão investigados.)

  • Docker no Mac

  • Docker no Windows

  • Rkt (container linux) do CoreOS

  • AppArmor em ambientes K3S / SLES. Certas configurações podem entrar em conflito com SUSE® Security e causar erros de scanner; o AppArmor deve ser desativado ao implantar SUSE® Security.

  • IPv6 não é suportado

  • VMWare Integrated Containers (VIC) exceto em modo aninhado

  • CloudFoundry

  • Console: IE 11 não é suportado devido a problemas de desempenho.

  • Host de contêiner aninhado em ferramentas de contêiner usadas para testes simples. Por exemplo, a implantação de um cluster Kubernetes usando 'kind' https://kind.sigs.k8s.io/docs/user/configuration/.

PKS é testado em campo e requer a habilitação de contêineres privilegiados no plano/tile, e a alteração do hostPath yaml da seguinte forma para Allinone, Controller, Enforcer:

            hostPath:
            path: /var/vcap/sys/run/docker/docker.sock

SUSE® Security suporta execução em VMs baseadas em Linux no Mac/Windows usando Vagrant, VirtualBox, VMware ou outros ambientes virtualizados.

Minikube

Por favor, faça as seguintes alterações no yaml de implantação do Allinone.

apiVersion: apps/v1 <<-- required for k8s 1.19
kind: DaemonSet
metadata:
 name: neuvector-allinone-pod
 namespace: neuvector
spec:
 selector: <-- Added
 matchLabels: <-- Added
 app: neuvector-allinone-pod <-- Added
 minReadySeconds: 60
...
 nodeSelector: <-- DELETE THIS LINE
 nvallinone: "true" <-- DELETE THIS LINE
apiVersion: apps/v1 <<-- required for k8s 1.19
kind: DaemonSet
metadata:
 name: neuvector-enforcer-pod
 namespace: neuvector
spec:
 selector: <-- Added
 matchLabels: <-- Added
 app: neuvector-enforcer-pod <-- Added

Desempenho e escalabilidade

Como sempre, o planejamento de desempenho para contêineres SUSE® Security dependerá de vários fatores, incluindo:

  • (Controller & Scanner) Número e tamanho das imagens no registro a serem escaneadas (pelo Scanner) inicialmente

  • (Enforcer) Modo de serviços (Descobrir, Monitorar, Proteger), onde o modo Proteger funciona como um firewall inline

  • (Enforcer) Tipo de conexões de rede para cargas de trabalho no modo Proteger

No modo Monitor (filtragem de rede semelhante a um espelho/tap), não há impacto no desempenho e o Enforcer lida com o tráfego na velocidade da linha, gerando alertas conforme necessário. No modo Proteger (firewall inline), o Enforcer requer CPU e memória para filtrar conexões com inspeção profunda de pacotes e mantê-las para determinar se devem ser bloqueadas/descartadas. Geralmente, com 1GB de memória e uma CPU compartilhada, o NeuVector Enforcer deve ser capaz de lidar com a maioria dos ambientes enquanto estiver no modo Proteger.

Para ambientes sensíveis à taxa de transferência ou à latência, memória adicional e/ou um núcleo de CPU dedicado podem ser alocados para o SUSE® Security contêiner do NeuVector Enforcer.

Para ajuste de desempenho do Controlador e Scanner para varredura de registro, veja os Requisitos do Sistema acima.

Para conselhos adicionais sobre desempenho e dimensionamento, veja a seção de Onboarding/Melhores Práticas.

Taxa de transferência

Como o gráfico abaixo mostra, testes de benchmark de taxa de transferência básicos mostraram uma taxa de transferência máxima de 1,3 Gbps POR NÓ em uma pequena instância de nuvem pública com 4 núcleos de CPU. Por exemplo, um cluster de 10 nós seria capaz de lidar com uma taxa de transferência máxima de 13 Gbps para todo o cluster para serviços no modo Proteger.

Taxa de transferência

Essa taxa de transferência seria projetada para aumentar à medida que uma CPU dedicada é atribuída ao NeuVector Enforcer, ou a velocidade da CPU muda, e/ou memória adicional é alocada. Novamente, a escalabilidade dependerá do tipo de tráfego de rede/aplicativo das cargas de trabalho.

Latência

A latência é outra métrica de desempenho que depende do tipo de conexões de rede. Semelhante à taxa de transferência, a latência não é afetada no modo Monitor, apenas para serviços no modo Proteger (firewall inline). Pacotes pequenos ou serviços simples/rápidos gerarão uma latência maior em SUSE® Security como uma porcentagem, enquanto pacotes maiores ou serviços que requerem processamento complexo mostrarão uma porcentagem menor de latência adicional pelo SUSE® Security NeuVector Enforcer.

A tabela abaixo mostra a latência média de 2-10% avaliada usando a ferramenta de benchmark Redis. O Benchmark Redis usa pacotes bastante pequenos, então espera-se que a latência com pacotes maiores seja menor.

Teste Monitorar Proteger Latência

PING_INLINE

34.904

31.603

9,46%

SET

38.618

36.157

6,37%

GET

36.055

35.184

2,42%

LPUSH

39.853

35.994

9,68%

RPUSH

37.685

36.010

4,45%

LPUSH (Benchmark LRANGE)

37.399

35.220

5,83%

LRANGE_100

25.539

23.906

6,39%

LRANGE_300

13.082

12.277

6,15%

O benchmark acima mostra a média de TPS do modo Proteger em comparação com o modo Monitor, e a latência adicionada para o modo Proteger em vários testes no benchmark. A principal maneira de reduzir a latência real (microsegundos) no modo Proteger é executar em um sistema com uma CPU mais rápida. Você pode encontrar mais detalhes sobre esta ferramenta de benchmark Redis de código aberto em https://redis.io/topics/benchmarks.

Adicionando Restrições de Escalonamento para Ambientes de Carga de Trabalho Grandes

Durante a instalação do NeuVector, se o seu sistema operacional host tiver uma grande quantidade de cargas de trabalho, os pods do NeuVector Enforcer podem falhar ao iniciar ao tentar abrir o grande volume de arquivos devido ao monitoramento do host dos pods. Isso também pode causar falhas no servidor RKE2 devido à grande quantidade de arquivos abertos.

Como uma solução alternativa para ambientes de carga de trabalho grandes, você precisa criar um arquivo como example-fs-max.conf na localização /etc/sysctl.d/ e adicionar restrições de escalonamento com a seguinte configuração:

fs.inotify.max_user_instances=8192
fs.inotify.max_user_watches=524288
fs.filemax=5000

Então, certifique-se de que a configuração seja aplicada com uma reinicialização através do seguinte comando:

systemctl restart systemd-sysctl