docs: adicionada politica estrita Zero-Root de privilégios mínimos para Docker e sistema
This commit is contained in:
+12
-6
@@ -244,13 +244,19 @@ Atualmente, a VPS 1 acumula as funções de **Gateway de Borda (Traefik)**, **Hu
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### 6. 🔒 Hardening Avançado de Containers
|
### 6. 🔒 Hardening de Privilégios Mínimos (Zero-Root) e Containers
|
||||||
Para garantir que a invasão de um container não resulte no comprometimento do sistema operacional host, aplicam-se as seguintes diretrizes de segurança no provisionamento de containers Docker:
|
Como princípio fundamental de segurança de toda a infraestrutura, **absolutamente nada e ninguém deve rodar ou possuir privilégios de `root`**, especialmente os ambientes de containers Docker e serviços locais. O privilégio de superusuário (`root`) é restrito exclusivamente ao administrador humano de forma temporária e monitorada via comandos `sudo` específicos.
|
||||||
|
|
||||||
* **No-New-Privileges**: Impede que processos dentro do container ganhem novos privilégios via binários `setuid` ou `setgid`.
|
* **🚫 Política de Zero-Root Geral**:
|
||||||
* **Read-Only Root Filesystem**: Monta o sistema de arquivos do container como apenas leitura, forçando gravações temporárias apenas em volumes declarados ou `/tmp` na memória (tmpfs).
|
* É expressamente proibido rodar serviços, scripts personalizados, bancos de dados, crons ou ferramentas de monitoramento como `root`.
|
||||||
* **CAP Drop**: Remove capacidades de sistema desnecessárias ao container (ex: `NET_ADMIN`, `SYS_ADMIN`, `SYS_CHROOT`).
|
* Todos os softwares do host devem rodar sob contas de sistema dedicadas e não privilegiadas (ex: usuário `deploy`, `postgres`, `git`, etc.).
|
||||||
* **Rootless Containers**: Sempre que suportado pela aplicação, os containers devem rodar com IDs de usuário não privilegiados (non-root).
|
|
||||||
|
* **🐋 Hardening Estrito no Docker**:
|
||||||
|
* **Docker Rootless Mode**: O motor do Docker Daemon deve ser instalado e operado no modo **Rootless** (sem privilégios de root no host). Isso garante que, mesmo que ocorra uma vulnerabilidade severa de escape de container ou comprometimento do daemon do Docker, o atacante ganhará apenas privilégios de um usuário comum e sem direitos administrativos no servidor principal.
|
||||||
|
* **Uso Obrigatório de Usuários Não Privilegiados (`USER`)**: É obrigatório declarar um usuário não root (ex: `USER node` ou `USER 1000:1000`) nas etapas finais de construção de todas as imagens Docker e arquivos `docker-compose.yml`. Nenhum processo interno de container pode rodar como UID `0` (root).
|
||||||
|
* **No-New-Privileges**: Todos os containers devem subir com a flag `--security-opt=no-new-privileges` ativa, impedindo que processos internos ganhem novos privilégios via binários `setuid` ou `setgid`.
|
||||||
|
* **Read-Only Root Filesystem**: O sistema de arquivos raiz do container deve ser montado como apenas leitura (`read_only: true`), limitando qualquer escrita temporária estritamente a volumes efêmeros montados em memória (`tmpfs`).
|
||||||
|
* **CAP Drop**: O container deve descartar todas as capacidades administrativas padrão do Linux Kernel (`cap_drop: [ "ALL" ]`) e habilitar estritamente apenas o mínimo necessário para a sua execução lógica básica.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user