Autonomia controlada

Rotinas e remediação

O Argus foi feito para detectar, explicar, notificar e só então agir, com segurança. O agente não executa comandos remotos arbitrários: as rotinas são uma lista fechada de ações, liberadas no host e no servidor, com aviso prévio, revalidação do estado, limite de frequência e auditoria completa.

Nesta página

Modos
Catálogo de ações
Duas chaves: host e servidor
Aprovar uma correção
Limpeza controlada de Docker

Modos

Modo	Comportamento
`notify_only` (padrão)	Só alerta e recomenda. Nada é executado.
`approval_required`	O plano fica esperando; um operador aprova ou rejeita no painel do alerta ou em Remediações.
`safe_auto`	Executa sozinho, mas só ações do catálogo seguro, com todas as travas.

Catálogo de ações

Ação	O que faz	Aprovação
`docker_disk_cleanup_dry_run`	Calcula quanto espaço uma limpeza liberaria, sem apagar nada.	não
`docker_disk_cleanup_controlled`	Remove imagens sem uso, build cache e containers parados e trunca logs de container grandes, quando o disco passa do limite. Nunca remove volumes.	não
`docker_prune_unused_images_dry_run`	Lista o espaço recuperável de imagens sem uso.	não
`docker_prune_unused_images`	Remove imagens sem nenhum container (rodando ou parado) criadas há mais de 7 dias. Respeita labels protegidas.	sim
`docker_swarm_save_node`	Analisa o processo que está derrubando um nó Swarm e só intervém se a política permitir.	sim
`journald_vacuum_dry_run`	Só mostra o uso de disco do journald.	não
`journald_vacuum`	Limpa o journald por idade/tamanho, sem apagar arquivos arbitrários.	sim
`fail2ban_sshd_protect`	Em força bruta SSH: instala o fail2ban se faltar e ativa o jail `sshd`. O IP que errar o login 5 vezes em 10 minutos fica bloqueado por 1 hora (nunca permanente). As redes do allowlist do agent nunca são bloqueadas.	sim
`package_upgrade`	No detalhe de uma vulnerabilidade de pacote (Segurança): atualiza os pacotes do host para a versão corrigida do repositório da distro. Nunca o kernel (exige reboot). Serviços do pacote podem reiniciar.	sim
`systemd_reset_failed`	Limpa o estado `failed` de units, sem iniciar, parar nem reiniciar.	não
`auto_resolve_normalized_alert`	Fecha alertas cujo check já voltou ao normal.	não

Duas chaves: host e servidor

Uma ação executada pelo agente só roda se estiver liberada nos dois lados.

No host

remediation:
  enabled: true
  default_mode: notify_only
  allow_arbitrary_commands: false
  allowed_actions:
    - docker_disk_cleanup_dry_run
    - docker_disk_cleanup_controlled
    - docker_swarm_save_node
    - journald_vacuum_dry_run
    - journald_vacuum
    - fail2ban_sshd_protect
    - package_upgrade

docker_prune_unused_images é aceita pelo agente quando docker_disk_cleanup_controlled já está liberada. O servidor nunca amplia o allowed_actions do host remotamente; isso só muda pelo arquivo ou pelo perfil do site na instalação.

No servidor e por site

A política do servidor decide o modo de cada regra. O perfil do site (Admin → Add Node → “Automático (runbook)”) liga uma ação em safe_auto só para os hosts daquele site, sem reinstalar. Uma regra marcada como sem remediação sempre vence.

Aprovar uma correção

O alerta abre e o servidor cria um plano em approval_required.
No painel do alerta (ou no pop-up Ver erro e correção), o operador lê a evidência e clica em Aprovar correção ou Rejeitar correção.
Aprovado, o agente executa no próximo ciclo, revalida o estado e devolve o resultado.
O resultado aparece em Histórico de remediação do alerta e na tela Remediações, e tudo fica no registro de auditoria.

Limpeza controlada de Docker

Fluxo esperado quando o disco enche:

O agente coleta o uso do filesystem.

O servidor abre o alerta de disco crítico e agenda docker_disk_cleanup_controlled.

O agente busca a tarefa, espera o aviso prévio (action_delay_seconds) e revalida o disco.

Se ainda estiver acima do limite, limpa imagens, cache e containers parados e trunca logs grandes.

O resultado volta ao servidor para auditoria.

Configuração no host (fora de collectors:):

remediation:
  enabled: true
  default_mode: safe_auto
  mode: safe_auto
  allow_arbitrary_commands: false
  allowed_actions:
    - docker_disk_cleanup_dry_run
    - docker_disk_cleanup_controlled

  docker_disk_cleanup:
    enabled: true
    mode: safe_auto
    partition: /
    threshold_percent: 90
    critical_threshold_percent: 95
    action_delay_seconds: 30
    cooldown_seconds: 86400
    revalidate_after_seconds: 10
    prune_images: true
    prune_build_cache: true
    prune_containers: true
    prune_volumes: false
    allow_volume_prune: false
    truncate_container_logs: true
    container_log_max_size_mb: 100
    truncate_only_if_disk_above_threshold: true

No servidor, a limpeza precisa estar habilitada no .env:

REMEDIATION_ENABLED=true
REMEDIATION_DEFAULT_MODE=safe_auto
DOCKER_DISK_CLEANUP_ENABLED=true
DOCKER_DISK_CLEANUP_MODE=safe_auto
DOCKER_DISK_CLEANUP_ALLOW_VOLUME_PRUNE=false

Forçar um teste

Num host de teste, reduza os limites temporariamente:

collectors:
  filesystem:
    warning_percent: 50
    critical_percent: 60

remediation:
  docker_disk_cleanup:
    threshold_percent: 50
    critical_threshold_percent: 60
    cooldown_seconds: 300

sudo systemctl restart argus-agent
sudo journalctl -u argus-agent -f
df -h /
docker system df

Volte cooldown_seconds para 86400 e os limites para os valores de produção depois do teste. A configuração segura nunca remove volumes: prune_volumes: false e allow_volume_prune: false. Containers e imagens com argus.protect, backup ou database são preservados.

Em produção, mantenha ações destrutivas em modo aprovado ou notify_only até que políticas, recursos protegidos, cooldowns e auditoria tenham sido validados.