Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Testes de ponta a ponta

Esta seção mostra como você pode escrever testes de ponta a ponta executados contra o binário WebAssembly real produzido pela ferramenta de compilação Javy.

Pré-requisitos

Lembre-se, você precisa dessas ferramentas em sua máquina de desenvolvimento:

bats: Usado para escrever os testes e automatizar sua execução.
kwctl >= v1.30: Ferramenta CLI fornecida por SUSE Security Admission Controller para executar suas políticas fora do Kubernetes, entre outras ações. Está coberto na seção de testes de políticas da documentação.

Escrevendo testes

Você usará bats para escrever e automatizar seus testes. Cada teste tem os seguintes passos:

Execute a política usando kwctl run diretamente com o arquivo de recurso JSON.
Realize as verificações contra a saída produzida por kwctl.

Todos os testes de ponta a ponta vão em um arquivo chamado e2e.bats. A estrutura do projeto inclui um exemplo, e2e.bats. Você precisa estender seu conteúdo para fornecer uma cobertura de teste abrangente para o comportamento da sua política.

Arquivos de dados de teste

Os casos de teste de ponta a ponta testam a criação de Recursos Kubernetes específicos.

Por exemplo, ao testar a criação de um recurso Pod:

{
  "apiVersion": "v1",
  "kind": "Pod",
  "metadata": {
    "name": "test-pod"
  },
  "spec": {
    "containers": [
      {
        "name": "nginx",
        "image": "nginx:latest"
      }
    ]
  }
}

O caso de teste de ponta a ponta usa um arquivo JSON contendo um AdmissionReview do Kubernetes. Esses objetos JSON AdmissionReviews são os que são enviados contra a API do Kubernetes para que sejam validados.

Você pode obter objetos JSON AdmissionReviews usando kwctl scaffold admission-request. Dê uma olhada em test_data/pod.json para ver um AdmissionRequest JSON com um Pod.

Casos de teste básicos

O template já fornece vários testes básicos. Veja como o arquivo completo e2e.bats deve parecer:

#!/usr/bin/env bats

Aqui estão os testes existentes com explicações:

Teste 1: Rejeitar nomes de host da lista de bloqueio

@test "reject because hostname is on deny list" {
  run kwctl run annotated-policy.wasm -r test_data/pod_with_hostname.json --settings-json '{"denied_hostnames": ["forbidden-host", "test-hostname"]}'

  # this prints the output when one of the checks below fails
  echo "output = ${output}"

  # request rejected
  [ "$status" -eq 0 ]
  [ $(expr "$output" : '.*allowed.*false') -ne 0 ]
  [ $(expr "$output" : ".*Pod hostname 'test-hostname' is not allowed.*") -ne 0 ]
}

Este teste garante que a política rejeite Pods quando seu nome de host está na lista de bloqueio.

Teste 2: Aceitar nomes de host permitidos

@test "accept because hostname is not on the deny list" {
  run kwctl run annotated-policy.wasm -r test_data/pod_with_hostname.json --settings-json '{"denied_hostnames": ["forbidden-host"]}'

  # this prints the output when one of the checks below fails
  echo "output = ${output}"

  # request accepted
  [ "$status" -eq 0 ]
  [ $(expr "$output" : '.*allowed.*true') -ne 0 ]
}

Este teste verifica se a política aceita Pods quando seu nome de host não está na lista de bloqueio.

Teste 3: Aceitar quando nenhuma configuração for fornecida

@test "accept because the deny list is empty" {
  run kwctl run annotated-policy.wasm -r test_data/pod_with_hostname.json

  # this prints the output when one of the checks below fails
  echo "output = ${output}"

  # request accepted
  [ "$status" -eq 0 ]
  [ $(expr "$output" : '.*allowed.*true') -ne 0 ]
}

Este teste garante que a política aceite solicitações quando você não fornecer configurações.

Teste 4: Aceitar pods sem nomes de host

@test "accept because pod has no hostname set" {
  run kwctl run annotated-policy.wasm -r test_data/pod.json --settings-json '{"denied_hostnames": ["forbidden-host"]}'

  # this prints the output when one of the checks below fails
  echo "output = ${output}"

  # request accepted (no hostname to check)
  [ "$status" -eq 0 ]
  [ $(expr "$output" : '.*allowed.*true') -ne 0 ]
}

Este teste verifica se a política aceita Pods sem nomes de host, independentemente da lista de bloqueio.

Teste 5: Aceitar recursos que não são Pods

@test "accept non-pod resources" {
  run kwctl run annotated-policy.wasm -r test_data/service.json --settings-json '{"denied_hostnames": ["forbidden-host"]}'

  # this prints the output when one of the checks below fails
  echo "output = ${output}"

  # request accepted (not a pod)
  [ "$status" -eq 0 ]
  [ $(expr "$output" : '.*allowed.*true') -ne 0 ]
}

Este teste garante que a política aceita recursos que não são Pods, uma vez que a política valida apenas os nomes de host dos Pods.

Cobertura de teste estendida

Você pode estender a cobertura de teste adicionando mais cenários de teste:

Teste 6: Validação de configurações

Você também pode adicionar testes para verificar se a validação de configurações funciona corretamente:

@test "accept valid settings" {
  run kwctl run annotated-policy.wasm -r test_data/pod.json --settings-json '{"denied_hostnames": ["host1", "host2"]}'

  # this prints the output when one of the checks below fails
  echo "output = ${output}"

  # settings are valid, request processed normally
  [ "$status" -eq 0 ]
  [ $(expr "$output" : '.*allowed.*true') -ne 0 ]
}

Teste 7: Casos extremos

@test "reject with multiple denied hostnames" {
  run kwctl run annotated-policy.wasm -r test_data/pod_with_hostname.json --settings-json '{"denied_hostnames": ["bad-host", "test-hostname", "forbidden-host"]}'

  # this prints the output when one of the checks below fails
  echo "output = ${output}"

  # request rejected
  [ "$status" -eq 0 ]
  [ $(expr "$output" : '.*allowed.*false') -ne 0 ]
  [ $(expr "$output" : ".*Pod hostname 'test-hostname' is not allowed.*") -ne 0 ]
}

@test "accept with empty denied hostnames array" {
  run kwctl run annotated-policy.wasm -r test_data/pod_with_hostname.json --settings-json '{"denied_hostnames": []}'

  # this prints the output when one of the checks below fails
  echo "output = ${output}"

  # request accepted
  [ "$status" -eq 0 ]
  [ $(expr "$output" : '.*allowed.*true') -ne 0 ]
}

Executando os testes

Você pode executar todos os testes de ponta a ponta usando este comando:

make e2e

Isso produz uma saída como:

bats e2e.bats
e2e.bats
 ✓ reject because hostname is on the deny list
 ✓ accept because hostname is not on the deny list
 ✓ accept because the deny list is empty
 ✓ accept because pod has no hostname set
 ✓ accept non-pod resources
 ✓ accept valid settings
 ✓ reject with multiple denied hostnames
 ✓ accept with empty denied hostnames array

8 tests, 0 failures

Entendendo a saída do teste

Cada teste usa kwctl para executar a política e verifica:

Status de saída: O comando kwctl deve sair com status 0 para a execução bem-sucedida da política.
Campo permitido: A saída JSON contém um campo allowed indicando se a solicitação foi aceita.
Conteúdo da mensagem: Para solicitações rejeitadas, a saída contém uma mensagem de erro descritiva.

As declarações echo "output = ${output}" em cada teste ajudam na depuração ao mostrar a saída real da política quando um teste falha.

Conclusão

Os testes de ponta a ponta fornecem uma cobertura abrangente do comportamento da política testando contra o binário WebAssembly real. Isso garante que a política funcione corretamente quando implantada em Admission Controller, não apenas no ambiente de desenvolvimento TypeScript.

Para exemplos mais abrangentes de testes de ponta a ponta, você pode explorar o código-fonte policy-sdk-js, que inclui testes e2e extensivos demonstrando cada uma das capacidades de host de Admission Controller. Esses testes podem servir de inspiração para testar recursos de política mais avançados, como rede, operações criptográficas e interações com o registro OCI.