Skip to content

đŸ”„ Quick Reference — 6 Incidents Critiques

Sauvé ma vie plusieurs fois. Si tu as 2 minutes, lis ça.

INC-001 : Variable GitLab CI Protected sur feature branch

Le problĂšme : Tu crĂ©es une variable SECRET_KEY avec "Protected" ✅, la mets dans une feature branch, et... elle n'est pas injectĂ©e ! đŸ€Š

Error: pydantic_core.ValidationError: SECRET_KEY Field required

Pourquoi : - Protected = injectĂ© uniquement sur branches protĂ©gĂ©es (main, develop) - Feature branch = pas protĂ©gĂ©e → variable pas disponible

Fix (30 secondes) :

Settings → CI/CD → Variables → SECRET_KEY
☐ Protected  →  ☑ Masked

RĂšgle d'or :

Protected  = production secrets SEULEMENT
Masked     = cache la valeur dans les logs (suffisant pour feature branches)

INC-002 : Pydantic BaseSettings lit .env avant env vars

Le problĂšme : Docker Compose → DB_HOSTNAME=db injected dans le container, mais ton app se connecte Ă  localhost:5432... qui n'existe pas en Docker ! đŸ’„

Connection refused: localhost:5432

Pourquoi :

Pydantic BaseSettings priorité :
1. Fichier .env (HAUTE) ← .env a DB_HOSTNAME=localhost
2. Variables d'environnement (BASSE)

Le fichier .env Ă©crase tout !

Fix :

# Créer .env.docker (séparé, pour Docker uniquement)
DB_HOSTNAME=db

RĂšgle d'or :

.env         = dev local (localhost)
.env.docker  = dev Docker Compose (db)
En CI/CD     = pas de fichier .env (variables injectées)

INC-005 : python-jose = CRITICAL CVE (algorithm confusion)

Le problĂšme : Tu utilises python-jose pour JWT, Trivy donne :

CRITICAL: python-jose algorithm confusion with ECDSA keys
CVE-2024-33663 (no fix available)

Et le projet python-jose est abandonnĂ© depuis 2023 ! 💀

Fix :

# requirements.in
- python-jose
+ PyJWT >= 2.12.0

# app/oauth2.py
- from jose import JWTError
+ from jwt.exceptions import InvalidTokenError

RĂšgle d'or :

Avant d'utiliser une lib : vérifier
- DerniĂšre release (< 1 an)
- Issues ouvertes (pas 500+)
- Mainteneurs actifs (Slack/Discord)
Outils : deps.dev, snyk advisor, PyPI stats

INC-010 : EKS Node Group bloqué sans NAT Gateway (27+ min)

Le problĂšme : terraform apply lance, les nodes EKS prennent 27+ minutes Ă  crĂ©er et finissent par Ă©chouer. 😮

module.eks.aws_eks_node_group.main: Still creating... [27m36s elapsed]
Error: nodes cannot reach Amazon ECR (internet access required)

Pourquoi :

EKS nodes doivent télécharger images Docker depuis ECR
Sans NAT Gateway → pas d'internet dans la VPC privĂ©e
Nodes essaient de démarrer, timeout, échec.

Fix :

# terraform/ephemeral/vpc.tf
resource "aws_nat_gateway" "main" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public.*.id[0]
}

# Et modifier la route table privée
route {
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id         = aws_nat_gateway.main.id
}

RĂšgle d'or :

EKS avec subnets privés = NAT Gateway OBLIGATOIRE
Pas de NAT = nodes bloqués, services impossibles à déployer
Coût : ~0.045$/h (à destroy le soir !)

INC-025 : Variables projet CI/CD Ă©crasent variables YAML

Le problĂšme : Tu dĂ©finis AWS_ACCESS_KEY_ID dans .gitlab-ci.yml, mais tu as aussi crĂ©Ă© une variable projet dans Settings → CI/CD → Variables. La variable projet gagne ! đŸ˜±

variables:
  AWS_ACCESS_KEY_ID: $AWS_INFRA_ACCESS_KEY_ID  # écrasée !

# La variable projet Settings → CI/CD → Variables gagne

Fix :

jobs:
  infra-start:
    before_script:
      - export AWS_ACCESS_KEY_ID=$AWS_INFRA_ACCESS_KEY_ID
      - export AWS_SECRET_ACCESS_KEY=$AWS_INFRA_SECRET_ACCESS_KEY

PrioritĂ© GitLab CI (haute → basse) :

1. Variables Trigger/Schedule
2. Settings → CI/CD → Variables (projet) ← TRÈS haute !
3. Variables fichier YAML
4. Variables groupe

RĂšgle d'or :

Si tu dois utiliser des secrets différents (gitlab_ci vs gitlab_ci_infra)
→ TOUJOURS utiliser before_script export pour forcer
→ Jamais compter sur les variables YAML seules

INC-044 : RĂ©gression lib Python kubernetes 36.0.0 → bootstrap 401

Le problĂšme : Ansible kubernetes.core renvoie 401 Unauthorized sur toutes les tasks, alors que kubectl get nodes passe juste avant avec les mĂȘmes credentials. đŸ€Ż

kubernetes.client.exceptions.UnauthorizedException: (401)
Reason: Unauthorized

Pourquoi :

Le client Python kubernetes 36.0.0 a une régression qui casse l'auth EKS.
Le MÊME token marche en kubectl ET curl brut (HTTP 200), mais le client v36 → 401.
Sur Alpine ET Ubuntu. pip install kubernetes (non pinné) tirait la 36 ;
une version antérieure marchait 4 jours avant.

Diagnostic (élimination méthodique) :

token   → curl brut HTTP 200 ✅ (token valide)
identitĂ© → kubectl auth whoami = bon user ✅
OS      → Ă©choue sur Ubuntu aussi ❌ (pas Alpine)
version → kubernetes==31.0.0 ✅ / 36.0.0 ❌  ← LA cause

Fix (1 ligne) :

- pip3 install kubernetes pyyaml --break-system-packages
+ pip3 install kubernetes==31.0.0 pyyaml --break-system-packages

RĂšgle d'or :

Pinner les versions des libs critiques en CI.
pip install <lib> sans version = une release upstream peut casser
l'infra du jour au lendemain, sans aucun changement de ton cÎté.
i/o timeout = réseau/CIDR | 401 = auth | 403 = autorisation

📌 Cheatsheet

Incident Quand ça arrive Fix rapide
INC-001 Feature branch + Protected var DĂ©sactiver Protected → Masked
INC-002 Docker Compose connection error Créer .env.docker
INC-005 Trivy CRITICAL JWT pip install PyJWT >= 2.12.0
INC-010 EKS nodes timeout 27+ min Ajouter NAT Gateway Terraform
INC-025 Credentials écrasées en CI Utiliser before_script export
INC-031 AmazonEKSClusterPolicy sur un user Policy custom eks:DescribeCluster uniquement
INC-032 eks:DescribeCluster manquant gitlab-ci Ajouter EKSConnect Ă  policy ecr_push
INC-033 kubectl cluster-info forbidden Remplacer par kubectl auth can-i -n fastapi
INC-035 Init:InvalidImageName ${ECR_IMAGE} yum install gettext + envsubst | kubectl apply
INC-036 DB_PASSWORD manquant dans secret Ajouter TF_VAR_db_password au secret K8s
INC-038 State lock = AccessDenied youss_admin Terraform = iamadmin uniquement
INC-039 Hardening absent du cluster (deploy fichier par fichier) kubectl apply -k k8s/base/ + kustomize set image
INC-040 terraform apply : accent dans description de SG Descriptions SG en anglais ASCII
INC-041 kubectl i/o timeout sur l'API EKS default: tags [ubuntu] (runner self-hosted, IP dans CIDR)
INC-044 bootstrap 401 (kubectl OK) pip install kubernetes==31.0.0 (régression v36)
INC-045 PSA absent sur EKS (deploy ne peut patcher le ns) Bootstrap crée le ns avec labels PSA, deploy ne gÚre plus le ns
INC-046 NetworkPolicy non enforced sur EKS (sortie port 80 OK) VPC CNI en addon managé + enableNetworkPolicy=true (#55)

🔍 Si tu cherches un incident spĂ©cifique

→ Utilise Rechercher (🔍 en haut à droite) → Explore les Sprints par chronologie

Bon courage ! 🚀