Pular para o conteúdo
início / methods / efficiency-security
Método transversal

Rode dezenas de contêineres em um servidor sem abrir mão do isolamento.

O compartilhamento de memória KSM empacota densidade no bare metal. Firecracker + LXC aplicam isolamento por contêiner. Impenetrabilidade da URL, segregação de realm e firewall em nível de host se somam — qualquer um pode falhar e os outros ainda contêm o dano.

KSM · LXC + Firecracker · AES-256 · espaço de chaves URL 2^192 · defesa em profundidade

Compartilhamento de páginas KSMLXC + FirecrackerEspaço de chaves URL 2^192AES-256 em repouso
início / methods / efficiency-security / density
Densidade KSM

Páginas compartilhadas, memória separada.

O Kernel Samepage Merging colapsa páginas de memória idênticas entre contêineres em cópias físicas únicas. Uma imagem base Debian, um runtime Node, uma instalação Postgres — todos os bytes que todo contêiner no servidor compartilha acabam contados uma única vez na RAM.

Páginas idênticas deduplicadas

Páginas de RAM com conteúdo idêntico (bibliotecas comuns, OS base, runtimes compartilhados) são mescladas. 30 contêineres Node em um servidor consomem muito menos memória do que 30× um contêiner.

Isolamento preservado

Os contêineres não conseguem ler a RAM uns dos outros. KSM é uma otimização de armazenamento — páginas mescladas se tornam copy-on-write. Qualquer escrita cria uma cópia privada instantaneamente.

Sem trabalho do lado do contêiner

KSM é no nível do kernel. As aplicações não precisam saber sobre isso. O contêiner vê memória Linux normal; o host vê deduplicação física.

Benefício dependente de carga

O benefício escala com o quanto os contêineres compartilham. Stacks similares = enorme dedup. Apps muito diferentes = menos dedup, mas páginas do OS base ainda se mesclam.

início / methods / efficiency-security / isolation
Camadas de virtualização

LXC + Firecracker. Namespaces de kernel + micro-VMs.

O Hoody usa um modelo de isolamento de dupla camada. LXC fornece isolamento leve de contêiner Linux via namespaces. Firecracker adiciona fronteiras de micro-VM assistidas por hardware onde uma separação mais forte importa. O kernel do host é hardened (base Linux 7.0.2-hoody) com filtragem de syscall via seccomp por cima.

Namespaces LXC

Processo, rede, montagem, usuário, PID, IPC — cada contêiner tem sua própria visão do kernel. Mecanismo Linux padrão, testado em escala.

Micro-VMs Firecracker

Fronteiras com virtualização por hardware. A tecnologia de isolamento do AWS Lambda. Aplicada onde um contêiner precisa de uma parede ainda mais forte do que namespaces sozinhos.

Kernel hardened

Base Linux 7.0.2-hoody com hardening de segurança. Filtros seccomp restringem quais syscalls um contêiner pode fazer.

Baseline bare-metal

Contêineres rodam no hardware do usuário. Sem hypervisor compartilhado com outros tenants. Sem canais laterais de vizinhos barulhentos do provedor de nuvem acima.

início / methods / efficiency-security / encryption
Dados em repouso

AES-256 em todo lugar que dados tocam o disco.

Criptografia do sistema de arquivos, swap criptografado, arquivos temporários criptografados. Desbloqueio remoto via sub-partição. O disco é texto cifrado; a descriptografia acontece na RAM na inicialização.

AES-256 no sistema de arquivos

Todo byte escrito no disco é criptografado. Perca o drive, não perca nada legível.

Swap + temporários criptografados

Páginas de swap e arquivos temporários nunca chegam ao disco em texto claro. Dumps de memória do kernel também são criptografados.

Desbloqueio remoto via sub-partição

O fluxo de boot suporta descriptografia remota via SSH no initramfs. Nenhuma chave de disco armazenada fisicamente com os dados.

início / methods / efficiency-security / urls
Impenetrabilidade da URL

2^192 combinações. Força bruta não é o ataque.

IDs de projeto têm 24 caracteres hexadecimais. IDs de contêiner têm 24 caracteres hexadecimais. Uma URL válida exige ambos. O espaço de chaves é 2^192 — a um trilhão de tentativas por segundo, a enumeração leva mais tempo do que a idade do universo. A impenetrabilidade é um padrão de partida, não a única camada.

Espaço de chaves de pares

2^192

Para enumerar a 1T/s

mais tempo que a idade do universo

Camadas adicionais disponíveis

JWT · Senha · IP · Token

Aberto por URL é o modo inicial. Bloqueie qualquer URL com JWT, HTTP Basic, IP CIDR ou bearer token via /platform/proxy — sem código de aplicação necessário.

início / methods / efficiency-security / defense
Defesa em profundidade

Seis camadas independentes. Qualquer falha deixa mais cinco.

Segurança é um stack, não um portão. Cada camada é independentemente eficaz; juntas fazem uma única falha sobrevivível.

1

Impenetrabilidade da URL

Espaço de chaves 2^192 em combos projeto+contêiner. A URL em si é o primeiro segredo.

2

Isolamento de contêiner

Namespaces LXC + micro-VMs Firecracker. Separação em nível de kernel.

3

Firewall em nível de host

Regras de entrada + saída aplicadas no host, não dentro do contêiner. À prova de adulteração.

4

Permissões do proxy

Grupos de auth JWT / Senha / IP / Token empilhados sobre URLs.

5

Segregação de realm

Isolamento de tenant no nível da API. Tokens com escopo para realms específicos.

6

Criptografia de disco

AES-256 em repouso. Swap criptografado. Boot com desbloqueio remoto.

início / methods / efficiency-security / observability
Observabilidade + MITM

Tudo é uma requisição HTTP inspecionável.

Trilhas de auditoria unificadas. Toda ação contra um contêiner é uma entrada no log do proxy. Qualquer serviço pode ser interceptado via hoody-exec ou hoody-curl para adicionar verificações de segurança de IA, logging ou limites de taxa sem modificar o serviço.

Logs de auditoria unificados

Os logs do proxy cobrem cada serviço. Consulta, exportação (NDJSON), agregação de estatísticas — tudo via API de logs do /platform/proxy.

MITM por design

Insira middleware entre qualquer serviço e seus clientes. Usado para portões de segurança de IA, logging de conformidade, limitação de taxa — sem alterações no serviço necessárias.

Fork da plataforma

Todo usuário pode interceptar a própria API do Hoody para personalizar o comportamento da plataforma — sem fazer fork do codebase.

início / methods / efficiency-security / revocation
Revogação instantânea

Suspeita de uma violação? Exclua o contêiner.

Toda URL de contêiner morre no momento em que o contêiner é excluído. Sem propagação de DNS. Sem invalidação de cache. Sem tokens antigos para rotacionar. A URL era a superfície; excluir o contêiner remove a superfície por completo.

DELETE /api/v1/containers/ID

Uma chamada de API. Autenticada com seu JWT ou token do control plane.

URL para de rotear

O proxy remove a entrada de roteamento. O hostname retorna 404 imediatamente — não 60 segundos depois.

Recrie em minutos

Crie um novo contêiner com um novo ID. Nova URL. A URL antiga está morta para sempre. Nenhuma credencial residual para rotacionar.

início / methods / efficiency-security / começar
Começar

Densidade e isolamento não são trocas aqui.

Bare metal. Kernel hardened. Disco criptografado. Defesa de seis camadas. Cada propriedade já é verdade no seu primeiro contêiner.

Guia de segurança

Veja também — /platform/proxy para permissões de URL e grupos de auth, /platform/control-plane para gerenciamento de realm/token, /methods/access-network para firewall + saída.