02 · INFRASTRUCTURE MANAGER

Infraestrutura pedida pelo catálogo, aplicada dentro da sua rede.

O engenheiro pede um Resource a partir de um resource schema que o seu time definiu. O Agente roda o Terraform na sua rede, e o state vai para o bucket da sua conta de cloud.

Falar com engenharia

Abre uma conversa no WhatsApp. Prefere e-mail? heimdall@yops.cloud

O que faz

O seu time decide o que pode ser pedido

Um resource schema define o tipo do recurso, os inputs que ele aceita — descritos num JSON Schema aplicado por inteiro, com enum, pattern e additionalProperties —, os valores padrão de cada environment e, se o seu time quiser, o módulo Terraform que o aplica. Um input fora da regra é recusado antes que qualquer coisa rode, e a recusa aponta o campo, nunca o valor.

Outra pessoa aprova

Quando o resource schema exige aprovação, criar ou alterar um Resource depende de outra pessoa aprovar, e ela aprova a versão do pedido que leu. Quem pediu não aprova o próprio pedido.

Módulos liberados por quem opera o Agente

Um módulo Terraform é código que roda com a credencial da sua nuvem. Por isso a lista de fontes permitidas fica na configuração do Agente, e não na API: um resource schema que aponta para fora dela não roda.

A região que o recurso pede

Na AWS, o recurso nasce na região que o Resource pede, ou na região da conta de cloud dele, e nunca numa região fixada pelo produto.

Trazer o que já existe e levar embora

Com heimdall resource import, um recurso criado fora do Heimdall passa a ser gerido por ele sem ser recriado. Já o heimdall terraform export monta um pacote que roda com terraform puro.

Apagar é apagar

heimdall resource delete roda só o destroy e destrói a infraestrutura de verdade. Um apply que ainda estava na fila não roda depois dele, e o Resource continua na lista como histórico.

Os providers que o Agente roda

AWS, GCP, Azure, Kubernetes, Helm e Cloudflare.

Como funciona

Um apply, do pedido ao state:

A API valida o pedido com base no resource schema e verifica se existe uma conta de cloud para aquele System e environment.
A API põe um job na fila. O registro do job guarda o pedido, nunca uma credencial.
Um Agente pega o job pelo canal que ele mesmo abriu, com TLS mútuo. O Agente só faz conexões de saída, e a API nunca abre conexão com ele.
Com federação OIDC, a API troca um token de 5 minutos por uma credencial temporária da sua nuvem, que segue para o Agente junto com o job e não é gravada. Com credencial estática, a API envia só a referência ao secret, e o Agente lê o valor no próprio store.
O Agente roda o Terraform numa versão fixada e conferida por SHA-256. O state vai para o bucket da conta, com o lock da própria nuvem.
O Agente devolve os outputs e o Resource passa a provisioned — ou a failed, com a saída do Terraform que explica o motivo. Cada job tem três tentativas, e o trabalho não se perde se o Agente cair no meio.

TERMINALheimdall resource

$ heimdall resource create --component 2a5e9fa9-e606-4306-883e-842f4082901d --schema a15f8f12-a127-44e0-99cd-3d2da4cc8c1d --environment 1f332b6d-e96f-85c4-a747-5a20deef94c9 --name recibos --input '{"bucket":"checkout-recibos"}'
✓ Resource created: recibos (5044c77d-f1c6-434c-adc3-cf5d03fe0e5c)

$ heimdall job list --component 2a5e9fa9-e606-4306-883e-842f4082901d --resource 5044c77d-f1c6-434c-adc3-cf5d03fe0e5c
JOB ID                                OPERATION  STATUS     ATTEMPTS  REASON  QUEUED AT
ef109461-1aa5-460a-b59c-ff2235c66371  apply      completed  1/3               2026-10-10T06:25:16.154935Z

$ aws --endpoint-url http://127.0.0.1:4666 s3 ls --recursive s3://terraform-state
2026-10-10 03:25:33       2770 heimdall/5044c77d-f1c6-434c-adc3-cf5d03fe0e5c.tfstate

Saída real de heimdall resource create e heimdall job list, com o state no bucket da conta.

Onde o dado fica

Tudo roda na sua infraestrutura. Mesmo assim, a divisão abaixo importa dentro da sua empresa, porque mostra quem, no seu time, tem acesso a quê.

Infrastructure Manager: onde o dado fica
NO AGENTE E NA SUA CONTA DE CLOUD	NA API, QUE É SUA
A execução do Terraform. O state e o lock, no bucket da conta de cloud de cada Resource, com um state por Resource. O Heimdall não guarda cópia. O valor de uma credencial estática, no store do Agente.	Os inputs e os outputs de cada Resource (um output marcado `sensitive` fica como `<sensitive>`). A saída do Terraform de cada job, com o plano, até 1 MiB por job. O registro de quem pediu, de quem aprovou e de cada execução. A credencial temporária passa pela API a caminho do Agente e não é gravada.

Ver a segurança

Quem aprova o quê

Infrastructure Manager: quem aprova o quê
ATO	QUEM
Criar, alterar e repetir um Resource	`owner` e `admin`, por padrão
Aprovar ou recusar	quem tem permissão para gerir Resources, e nunca quem pediu
Apagar, que destrói a infraestrutura	quem tem permissão para apagar, que uma `policy` pode restringir
Registrar e vincular contas de cloud	`owner` e `admin`; `member` não vê as contas
Decidir quais módulos Terraform rodam	quem opera o Agente, na configuração dele
Ler Resources e jobs	todo membro

Com os outros módulos

01

Catálogo

O Resource nasce sob um Component e pertence a um System. A conta de cloud é resolvida primeiro pelo System, depois pelo Domain e, por fim, pela organização.
03

Secret Manager

Uma credencial estática é um secret no Agente, e a API nunca lê o valor dela.
07

Incident Manager

Um incidente pode ser aberto sobre um Resource.

Converse com quem constrói o Heimdall.

Conte como a sua engenharia guarda secrets e acessa o banco hoje. Respondemos dizendo o que o Heimdall colocaria sob regra primeiro e como a implantação chegaria lá.