GustavoNogueira/A-Team-Security-Infra-Agent-Engineer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: add explicit security rules multi-line example to TF validation checklist

Browse Source
This commit is contained in:
nogueiraguh
2026-03-08 19:03:27 -03:00
parent 6065ba7b12
commit 28a8fe4511
1 changed files with 11 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
backend/app.py
View File

@@ -2074,15 +2074,22 @@ Antes de entregar qualquer código (novo ou corrigido), valide TODOS os itens ab
12. **Tipos de recursos existentes**: usar SOMENTE resource types que existem no provider oracle/oci. Recursos inventados ou de outros providers causam erro fatal. Se um recurso não existe, REMOVA-O e substitua pela alternativa correta. 12. **Tipos de recursos existentes**: usar SOMENTE resource types que existem no provider oracle/oci. Recursos inventados ou de outros providers causam erro fatal. Se um recurso não existe, REMOVA-O e substitua pela alternativa correta.
13. **Variable "region"**: SEMPRE declarar `variable "region" {}` no `variables.tf`, mesmo em cenários multi-região com variáveis separadas (ex: `region_mad1`, `region_mad3`). O sistema injeta `region` via `terraform.tfvars` e sem essa declaração o Terraform emite warning. A variável deve existir para compatibilidade mesmo que não seja usada diretamente nos recursos. 13. **Variable "region"**: SEMPRE declarar `variable "region" {}` no `variables.tf`, mesmo em cenários multi-região com variáveis separadas (ex: `region_mad1`, `region_mad3`). O sistema injeta `region` via `terraform.tfvars` e sem essa declaração o Terraform emite warning. A variável deve existir para compatibilidade mesmo que não seja usada diretamente nos recursos.
14. **Dependências de peering**: Remote Peering Connections devem existir em AMBOS os lados antes de configurar o peering. Usar referências cruzadas entre RPCs para garantir a ordem de criação (ex: `peer_id = oci_core_remote_peering_connection.rpc_secondary.id`). 14. **Dependências de peering**: Remote Peering Connections devem existir em AMBOS os lados antes de configurar o peering. Usar referências cruzadas entre RPCs para garantir a ordem de criação (ex: `peer_id = oci_core_remote_peering_connection.rpc_secondary.id`).
15. **Sintaxe de blocos HCL**: NUNCA usar sintaxe single-line para blocos com múltiplos argumentos. Usar SEMPRE multi-line: 15. **Sintaxe de blocos HCL**: NUNCA usar sintaxe single-line para blocos com múltiplos argumentos. Usar SEMPRE multi-line com um argumento por linha:
- ERRADO: `ingress_security_rules { protocol = "6" source = "10.0.0.0/16" stateless = false }`
- ERRADO: `match_criteria { match_type = "DRG_ATTACHMENT_ID" drg_attachment_id = oci_core_drg_attachment.x.id }` - ERRADO: `match_criteria { match_type = "DRG_ATTACHMENT_ID" drg_attachment_id = oci_core_drg_attachment.x.id }`
- CORRETO: - CORRETO:
```hcl ```hcl
match_criteria { ingress_security_rules {
match_type = "DRG_ATTACHMENT_ID" protocol = "6"
drg_attachment_id = oci_core_drg_attachment.x.id source = "10.0.0.0/16"
stateless = false
tcp_options {
min = 443
max = 443
}
} }
``` ```
O erro "Invalid single-argument block definition" ocorre quando HCL encontra `bloco { a = 1, b = 2 }` com mais de um argumento. SEMPRE usar formato multi-line.
Isso vale para TODOS os blocos: `ingress_security_rules`, `egress_security_rules`, `route_rules`, `match_criteria`, `tcp_options`, `udp_options`, etc. Isso vale para TODOS os blocos: `ingress_security_rules`, `egress_security_rules`, `route_rules`, `match_criteria`, `tcp_options`, `udp_options`, etc.
""" """