Empêcher la copie de .env.auto dans storage/ - Supprimé la ligne copiant .env.auto vers storage/dev/ dans replace_variables_and_copy.sh - Mis à jour README.md pour refléter que .env.auto n'est plus copié dans storage/ - .env.auto reste dans templates/dev/ pour le traitement des variables mais n'est pas déployé
4NK Vault API - Système Sécurisé
API HTTPS sécurisée avec authentification par clés utilisateur et chiffrement quantique résistant.
🔐 Sécurité Avancée
- HTTPS obligatoire sur le port 6666
- Authentification par ID utilisateur (header
X-User-ID) - Clés individuelles par utilisateur ET par environnement
- Rotation automatique des clés (toutes les heures)
- Chiffrement quantique résistant (ChaCha20-Poly1305)
- Stockage sécurisé dans
storage/<env>/_keys/ - Traitement des variables d'environnement en mémoire
- Protection contre les attaques de traversée de chemins
🚀 Fonctionnalités
Authentification
- ID utilisateur requis pour tous les accès
- Validation stricte : 3-128 caractères alphanumériques +
_et- - Clés uniques par combinaison utilisateur/environnement
- Support des clés longues (hash SHA256 des IDs utilisateur)
Gestion des clés
- Génération automatique de clés de 32 bytes
- Rotation automatique toutes les heures
- Sauvegarde de l'ancienne clé pour compatibilité
- Isolation par environnement (dev, prod, etc.)
Variables d'environnement
- Génération automatisée des variables depuis les templates
- Résolution multi-passes des variables imbriquées (
$VARet${VAR}) - Chargement séquentiel :
.env.secrets,.env,.env.auto,.env.post - Traitement en mémoire avec résolution récursive
- Protection contre les dépendances circulaires
📋 Endpoints
GET /health
Contrôle de santé avec authentification.
Headers requis :
X-User-ID: your_user_id
Réponse :
{
"status": "healthy",
"service": "vault-api-secure",
"encryption": "quantum-resistant",
"algorithm": "X25519-ChaCha20-Poly1305",
"authentication": "user-key-based",
"key_rotation": "automatic",
"user_id": "your_user_id",
"timestamp": "2024-01-01T00:00:00"
}
GET /info
Informations sur l'API avec authentification.
GET /routes
Liste toutes les routes disponibles avec exemples de fichiers.
GET /<env>/<file>
Sert un fichier chiffré avec authentification utilisateur et variables d'environnement résolues.
Headers requis :
X-User-ID: your_user_id
Exemple :
curl -k -H "X-User-ID: <VAULT_USER_ID>" "$VAULT_URL"/dev/bitcoin/bitcoin.conf
🔧 Installation et utilisation
Prérequis
- Python 3.8+
- pip
Installation
# Cloner le repository
git clone https://git.4nkweb.com:4nk/4NK_vault.git
cd 4NK_vault
# Créer l'environnement virtuel
python3 -m venv venv_api
source venv_api/bin/activate
# Installer les dépendances
pip install -r requirements.txt
Génération des configurations
# Générer toutes les configurations depuis les templates
cd templates/dev
./generate.sh
# Ou manuellement étape par étape
./generate_variables.sh # Génère les variables d'environnement
./generate_grafana_dashboards.sh # Génère les dashboards Grafana
./generate_promtail_config.sh # Génère la configuration Promtail
./generate_logrotate_configs.sh # Génère les configurations logrotate
./generate_nginx_configs.sh # Génère les configurations nginx
./replace_variables_and_copy.sh # Résout les variables et copie vers storage/
Démarrage
# Démarrer l'API sécurisée
./start_api.sh
# Ou manuellement
source venv_api/bin/activate
python3 api_server.py
Test
# Tester l'API sécurisée
python3 test_api.py
🔐 Sécurité
Authentification
- ID utilisateur obligatoire pour tous les accès
- Validation stricte des caractères autorisés
- Rejet automatique des requêtes non authentifiées
Chiffrement
- Clés individuelles par utilisateur et environnement
- ChaCha20-Poly1305 (quantum-résistant)
- Rotation automatique des clés
- Métadonnées sécurisées dans le payload
- Compatibilité API/SDK avec
@noble/ciphers
Variables d'environnement
- Système de templates automatisé : génération et résolution des variables
- Support des syntaxes
$VARet${VAR}avec résolution multi-passes - Dépendances récursives résolues automatiquement (jusqu'à 5 passes)
- Protection contre les boucles infinies et dépendances circulaires
- Workflow automatisé : templates → génération → résolution → stockage
Stockage
- Isolation par environnement :
storage/<env>/_keys/ - Fichiers protégés dans
.gitignore - Aucune clé côté client
📁 Structure
4NK_vault/
├── api_server.py # Serveur sécurisé principal (lit storage/)
├── start_api.sh # Script de démarrage sécurisé
├── test_api.py # Tests de l'API sécurisée
├── requirements.txt # Dépendances Python
├── SECURITY_NOTICE.md # Avertissements de sécurité
├── templates/ # Templates sources avec variables ($VAR)
│ ├── dev/
│ │ ├── generate.sh # Script principal d'orchestration
│ │ ├── generate_variables.sh # Génération des variables d'environnement
│ │ ├── generate_grafana_dashboards.sh # Génération des dashboards Grafana
│ │ ├── generate_promtail_config.sh # Génération de la config Promtail
│ │ ├── generate_logrotate_configs.sh # Génération des configs logrotate
│ │ ├── generate_nginx_configs.sh # Génération des configs nginx
│ │ ├── replace_variables_and_copy.sh # Résolution des variables + copie
│ │ ├── .env.secrets # Variables sensibles
│ │ ├── .env # Variables principales
│ │ ├── .env.post # Variables finales/composites
│ │ ├── _4NK_modules/ # Modules avec configurations
│ │ ├── 4NK_modules/ # Modules générés (Grafana, Promtail)
│ │ ├── logrotade/ # Configurations logrotate
│ │ └── nginx/ # Configurations nginx
│ └── prod/ # Templates pour l'environnement de production
├── storage/ # Fichiers finaux avec variables résolues (lecture seule par API)
│ ├── dev/
│ │ ├── .env.auto # Variables générées avec valeurs résolues
│ │ ├── docker-compose.yml.auto # Docker Compose avec variables résolues
│ │ ├── _keys/ # Clés utilisateur (auto-créé)
│ │ ├── _4NK_modules/ # Configurations avec variables résolues
│ │ ├── 4NK_modules/ # Modules générés avec variables résolues
│ │ ├── logrotade/ # Configurations logrotate avec variables résolues
│ │ └── nginx/ # Configurations nginx avec variables résolues
│ └── prod/ # Fichiers finaux pour la production
├── sdk-client/ # Client TypeScript avec chiffrement
│ ├── src/
│ │ └── index.ts # Client sécurisé avec @noble/ciphers
│ ├── examples/
│ │ └── usage.ts # Scénario complet 5 étapes
│ ├── .env # Configuration SDK (VAULT_USER, VAULT_KEY, VAULT_ENV)
│ └── dist/ # Code compilé TypeScript
└── docs/ # Documentation complète
🌐 Intégration dans l'environnement 4NK
Ce module s'intègre au déploiement global 4NK via une URL de base configurable (variable VAULT_URL).
Consultez les documents centraux pour le contexte et l'orchestration:
docs/DEEP_ARCHITECTURE_ANALYSIS.mddocs/TECHNICAL_REFERENCE.mddocs/DEPLOYMENT_GUIDE.md
⚠️ Avertissements
Voir SECURITY_NOTICE.md pour les détails sur les limitations de sécurité en mode démonstration.
📋 Fichiers centralisés
Les fichiers suivants sont centralisés dans le dépôt principal 4NK_env :
CODE_OF_CONDUCT.md- Code de conduiteCODEOWNERS- Propriétaires du codeCONTRIBUTING.md- Guide de contributionLICENSE- Licence du projet
🚀 Politique NGINX
Introduction
La configuration retenue met en place un reverse-proxy Nginx conteneurisé qui sert de point d'entrée unique. Elle distingue clairement les flux externes (terminaison TLS en 443) et les flux internes intra-Docker (routés par ports Nginx 8081/8082, non publiés sur l'hôte). Les applications tournent dans des conteneurs dédiés app1 (8081) et app2 (8082). Les en-têtes de traçabilité sont normalisés et les redirections sont maîtrisées pour éviter toute boucle.
🏗️ Architecture Générale
Configuration Fonctionnelle
- Nginx conteneurisé : Partage le réseau Docker
app_netavec app1 et app2 - Ports externes : 80 et 443 publiés vers l'hôte pour l'accès externe
- Ports internes : 8081 et 8082 non publiés (accessibles uniquement depuis les conteneurs)
Flux de Trafic
Flux Externes :
- Port 80 → Redirection 301 vers port 443
- Port 443 → Terminaison TLS + proxy vers upstream HTTP (app1:8081 ou app2:8082)
Flux Internes Intra-Docker :
http://nginx:8081/→ Nginx (port 8081) → app1:8081http://nginx:8082/→ Nginx (port 8082) → app2:8082
🔧 Configuration Technique
Docker Compose
nginx:
ports:
- "80:80"
- "443:443"
volumes:
- ./nginx/conf.d:/etc/nginx/conf.d
- ./nginx/snippets:/etc/nginx/snippets
- ./certs:/etc/nginx/certs
- ./logs:/var/log/nginx
depends_on:
- app1
- app2
networks:
- app_net
app1:
expose:
- "8081"
networks:
- app_net
app2:
expose:
- "8082"
networks:
- app_net
Upstreams (nginx/conf.d/upstreams.conf)
upstream app1_docker {
server app1:8081;
keepalive 32;
}
upstream app2_docker {
server app2:8082;
keepalive 32;
}
# Format de logs JSON pour l'observabilité
log_format app_json escape=json
'{ "time":"$time_iso8601",'
' "client":"$remote_addr",'
' "xff":"$http_x_forwarded_for",'
' "method":"$request_method",'
' "host":"$host",'
' "uri":"$request_uri",'
' "status":$status,'
' "bytes":$body_bytes_sent,'
' "ua":"$http_user_agent",'
' "upstream":"$upstream_addr",'
' "rt":$request_time,'
' "urt":$upstream_response_time }';
Headers Proxy (nginx/snippets/proxy_headers.conf)
proxy_http_version 1.1;
# Headers de base
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Connection "";
# Directives anti-boucle et debug
proxy_redirect off;
add_header X-Debug-Scheme $scheme always;
add_header X-Debug-XFP $http_x_forwarded_proto always;
# Timeouts et buffers
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
proxy_buffering on;
proxy_buffers 32 16k;
client_max_body_size 50m;
🌐 Configuration des VHosts
VHosts Externes (Ports 80/443)
Redirection HTTP → HTTPS :
server {
listen 80;
server_name app1.exemple.tld app2.exemple.tld;
return 301 https://$host$request_uri;
}
Terminaison HTTPS :
server {
listen 443 ssl http2;
server_name app1.exemple.tld;
ssl_certificate /etc/nginx/certs/fullchain.pem;
ssl_certificate_key /etc/nginx/certs/privkey.pem;
location / {
include snippets/proxy_headers.conf;
proxy_pass http://app1_docker;
# Support WebSocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600s;
}
}
VHosts Internes (Ports 8081/8082)
server {
listen 8081 default_server;
server_name _;
location / {
include snippets/proxy_headers.conf;
proxy_pass http://app1_docker;
}
}
server {
listen 8082 default_server;
server_name _;
location / {
include snippets/proxy_headers.conf;
proxy_pass http://app2_docker;
}
}
⚠️ Points d'Attention Opérationnels
Configuration des Applications
- Confiance Proxy : Activer l'interprétation des headers
X-Forwarded-ProtoetX-Forwarded-Host - Frameworks Supportés : Django/Flask, Rails, Express, Spring, Go frameworks, etc.
- Redirection Réflexe : Condition nécessaire pour éviter les boucles de redirection
Sécurité
- HSTS : Ne pas activer sur les ports internes 8081/8082
- HSTS Externe : Réserver aux vhosts externes en 443 si tout le domaine est en HTTPS
- CDN/Proxy Amont : Compléter avec
real_ip_header/set_real_ip_frompour fiabiliser$remote_addr
🧪 Tests de Non-Régression
Tests Externes
# Redirection HTTP → HTTPS
curl -I http://app1.exemple.tld/
# Attendu: 301 Location: https://app1.exemple.tld/...
# Accès HTTPS direct
curl -I https://app1.exemple.tld/
# Attendu: 200 (pas de 3xx)
Tests Internes
# Depuis un conteneur sur app_net
curl -I http://nginx:8081/
curl -I http://nginx:8082/
# Attendu: 200 (pas de 3xx)
📋 Conclusion
La Variante A intra-Docker fournit un schéma propre :
- Externe : HTTPS avec redirection unique depuis le port 80
- Interne : Nginx sur ports 8081/8082 sans exposition vers l'hôte
- En-têtes standardisés : Traçabilité et robustesse garanties
- Anti-boucles :
proxy_redirect offet headers de debug - WebSocket : Support natif avec timeouts étendus
Cette base est prête pour la production et extensible à d'autres services.
Voir : 4NK_env/CODE_OF_CONDUCT.md, 4NK_env/CODEOWNERS, 4NK_env/CONTRIBUTING.md, 4NK_env/LICENSE