Sécurité des bases de données

Maintenir la sécurité de vos systèmes de bases de données est primordial pour protéger les informations sensibles et garantir l'intégrité de vos données. Ce guide fournit des étapes complètes pour mettre à jour les paramètres de sécurité des bases PostgreSQL et Redis, y compris les changements de mot de passe, la rotation des clés de chiffrement et les mises à jour des certificats clients. Suivez ces procédures avec soin pour renforcer la posture de sécurité de vos bases.

Mettre à jour le mot de passe PostgreSQL

Garantissez la sécurité de votre base PostgreSQL en définissant un nouveau mot de passe.

attention

Veillez à sauvegarder votre base avant de démarrer cette procédure, qui entraînera une interruption minimale de l'application — du scaling down jusqu'au redéploiement complet.

1. Réduisez le nombre de réplicas du Dashboard, de l'API publique et des récepteurs de webhooks.

kubectl --namespace <namespace> get deploy -o name \
   | grep webapp \
   | xargs kubectl --namespace <namespace> scale deploy/% --replicas 0

Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).

2. Confirmez que toutes les tâches asynchrones et planifiées sont terminées.

kubectl exec --namespace <namespace> -t deploy/worker-scanners \
    -- celery -A ward_run_app inspect active

La sortie devrait indiquer - empty - pour chaque pod, signalant la complétion.

app@(...):/app$ celery -A ward_run_app inspect active
(...)
->  workers@worker-worker-(...): OK
    - empty -
->  long_tasks@worker-long-tasks-(...): OK
    - empty -
->  scanner@worker-scanners-(...): OK
    - empty -
->  email@worker-email-(...): OK
    - empty -
->  email@worker-email-(...): OK
    - empty -
->  scanner@worker-scanners-(...): OK
    - empty -
->  long_tasks@worker-long-tasks-(...): OK
    - empty -
->  workers@worker-worker-(...): OK
    - empty -

3. Réduisez le nombre de réplicas de tous les workers et pods de scheduler.

kubectl --namespace <namespace> get deploy -o name \
   | grep worker \
   | xargs kubectl --namespace <namespace> scale deploy/% --replicas 0

Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).

4. Configurez votre environnement, mettez à jour le namespace gg_namespace selon vos besoins.

gg_namespace=<namespace>
pg_host=$(kubectl -n $gg_namespace get cm gim-config -o jsonpath="{.data.POSTGRES_HOST}")
pg_port=$(kubectl -n $gg_namespace get cm gim-config -o jsonpath="{.data.POSTGRES_PORT}")
pg_user=$(kubectl -n $gg_namespace get cm gim-config -o jsonpath="{.data.POSTGRES_USER}")
pg_passwd=$(kubectl -n $gg_namespace get secret gim-secrets -o jsonpath="{.data.POSTGRES_PASSWORD}" | base64 -d)
pg_db=$(kubectl -n $gg_namespace get cm gim-config -o jsonpath="{.data.POSTGRES_DB}")

5. Avec votre environnement défini, vous êtes prêt à lancer un shell PostgreSQL.

echo "Connection to $pg_user@$pg_host:$pg_port/$pg_db"
kubectl -n $gg_namespace run postgresql-client --rm -it \
  --restart='Never' --image docker.io/bitnamilegacy/postgresql:13 \
  --env="PGPASSWORD=$pg_passwd" --command \
  -- psql --host $pg_host -U $pg_user -d $pg_db -p $pg_port

6. Dans le shell, mettez à jour votre mot de passe.

ALTER USER <postgres user> WITH PASSWORD '<new password>';

Remplacez <postgres user> par votre nom d'utilisateur et <new password> par le mot de passe souhaité.

Installation via KOTS

1. Naviguez jusqu'à l'onglet « Config » dans la console d'administration KOTS et mettez à jour le mot de passe PostgreSQL.
2. Enregistrez la configuration.
3. Déployez la configuration mise à jour.

Installation via Helm

attention

Ne modifiez pas directement les valeurs dans le secret Kubernetes gim-secrets, car ces changements seront écrasés par les mises à niveau Helm suivantes.

1. Pour la gestion des secrets, assurez-vous que les mises à jour sont faites au bon endroit selon votre configuration. Regardez votre fichier de values sous la section postgresql pour trouver comment le mot de passe est stocké. Pour plus de détails, voir Helm sensitive information management.

• Si vous utilisez un secret manager, modifiez les valeurs requises dedans.
• Si vous utilisez un secret à l'intérieur du namespace, patchez-le :

kubectl patch secret -n $gg_namespace gim-secrets \
   -p "{\"data\":{\"POSTGRES_PASSWORD\":\"$(echo '<new_password>' | base64)\"}}"

2. Une fois le nouveau mot de passe défini, vous pouvez redéployer l'application :

helm upgrade <release-name> -n <namespace> -f local-values.yaml

Remplacez <release-name> par le nom de release que vous avez spécifié lors de l'installation initiale (utilisez helm ls pour le retrouver). Si nécessaire, précisez le namespace Kubernetes avec -n (le namespace par défaut est utilisé sinon). Conservez la même version via le flag --version.

Mettre à jour le mot de passe Redis main (cluster externe)

Le processus de mise à jour du mot de passe Redis main varie selon la méthode d'installation :

• Installation Redis standard : créez une nouvelle instance avec des paramètres identiques ou mettez à jour directement le mot de passe dans le fichier de configuration de l'instance existante.
• AWS Elasticache : utilisez l'AWS CLI ou l'API pour suivre les directives Rotate AUTH token.
• GCP Memorystore : modifiez la chaîne AUTH en basculant AUTH d'off à on.
• Helm chart Bitnami : dans le fichier de values du Helm chart Redis, modifiez la valeur global.redis.password avec le nouveau mot de passe. Appliquez les changements avec helm upgrade <redis-release> -f <redis-values.yaml>.

Installation via KOTS

1. Naviguez jusqu'à l'onglet « Config » dans la console d'administration KOTS et mettez à jour le mot de passe PostgreSQL.
2. Enregistrez la configuration.
3. Déployez la configuration mise à jour.

Installation via Helm

attention

Ne modifiez pas directement les valeurs dans le secret Kubernetes gim-secrets, car ces changements seront écrasés par les mises à niveau Helm suivantes.

1. Pour la gestion des secrets, assurez-vous que les mises à jour sont faites au bon endroit selon votre configuration. Regardez votre fichier de values sous la section redis.main pour trouver comment le mot de passe est stocké. Pour plus de détails, voir Helm sensitive information management.

• Si vous utilisez un secret manager, modifiez les valeurs requises dedans.
• Si vous utilisez un secret à l'intérieur du namespace, patchez-le :

kubectl patch secret -n <namespace> <secret_name> \
  -p "{\"data\":{\"REDIS_URL\":\"<redis|rediss>://:$(echo -n '<new_password>' | base64)@<redis_host>:<redis_port>\"}}"

2. Une fois le nouveau mot de passe défini, vous pouvez redéployer l'application :

helm upgrade <release-name> -n <namespace> -f local-values.yaml

Remplacez <release-name> par le nom de release que vous avez spécifié lors de l'installation initiale (utilisez helm ls pour le retrouver). Si nécessaire, précisez le namespace Kubernetes avec -n (le namespace par défaut est utilisé sinon). Conservez la même version via le flag --version.

Mettre à jour le mot de passe Redis main (cluster embedded)

Remplacez la valeur de la clé redis-password dans le secret redis par votre nouveau mot de passe.

NEWPASSWORD=$(echo -n '<new password>' | base64)
kubectl patch secret --namespace <namespace> redis \
   -p "{\"data\":{\"redis-password\":\"${NEWPASSWORD}\"}}"

Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).

Mettre à jour le certificat client PostgreSQL (cluster externe)

info

Cette procédure est destinée aux configurations PostgreSQL utilisant mTLS (Mutual TLS). Soyez conscient que la configuration de PostgreSQL pour utiliser des certificats clients n'est pas faisable avec AWS RDS.

attention

Veillez à sauvegarder votre base avant de démarrer cette procédure, qui entraînera une interruption minimale de l'application — du scaling down jusqu'au redéploiement complet.

1. Réduisez le nombre de réplicas du Dashboard, de l'API publique et des récepteurs de webhooks.

kubectl --namespace <namespace> get deploy -o name \
   | grep webapp \
   | xargs kubectl --namespace <namespace> scale deploy/% --replicas 0

Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).

2. Confirmez que toutes les tâches asynchrones et planifiées sont terminées.

$ kubectl exec --namespace <namespace> -t deploy/worker-scanners \
   -- celery -A ward_run_app inspect active

La sortie devrait indiquer - empty - pour chaque pod, signalant la complétion.

app@(...):/app$ celery -A ward_run_app inspect active
(...)
->  workers@worker-worker-(...): OK
    - empty -
->  long_tasks@worker-long-tasks-(...): OK
    - empty -
->  scanner@worker-scanners-(...): OK
    - empty -
->  email@worker-email-(...): OK
    - empty -
->  email@worker-email-(...): OK
    - empty -
->  scanner@worker-scanners-(...): OK
    - empty -
->  long_tasks@worker-long-tasks-(...): OK
    - empty -
->  workers@worker-worker-(...): OK
    - empty -

3. Réduisez le nombre de réplicas de tous les workers et pods de scheduler.

kubectl --namespace <namespace> get deploy -o name \
   | grep worker \
   | xargs kubectl --namespace <namespace> scale deploy/% --replicas 0

Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).

4. Le processus de mise à jour du certificat client PostgreSQL varie selon la méthode d'installation :

• GCP Cloud SQL : créez un nouveau certificat client en suivant la procédure.

Installation via KOTS

1. Naviguez jusqu'à l'onglet « Config » dans la console d'administration KOTS et mettez à jour le mot de passe PostgreSQL.
2. Enregistrez la configuration.
3. Déployez la configuration mise à jour.

Installation via Helm

attention

Ne modifiez pas directement les valeurs dans le secret Kubernetes gim-secrets, car ces changements seront écrasés par les mises à niveau Helm suivantes.

1. Pour la gestion des secrets, assurez-vous que les mises à jour sont faites au bon endroit selon votre configuration. Regardez votre fichier de values sous la section postgresql pour trouver comment le mot de passe est stocké. Pour plus de détails, voir Helm sensitive information management.

• Si vous utilisez un secret manager, modifiez les valeurs requises dedans.
• Si vous utilisez un secret à l'intérieur du namespace, patchez-le :

kubectl patch secret --namespace <namespace> <secret-name>\
   -p "{\"data\": { \"pg_client.key\": \"$(base64 -w0 ./tls.key)\", \"pg_client.crt\": \"$(base64 -w0 ./tls.crt)\"}}"

Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).

2. Une fois le nouveau certificat et la nouvelle clé définis, vous pouvez redéployer l'application :

helm upgrade <release-name> -n <namespace> -f local-values.yaml

Remplacez <release-name> par le nom de release que vous avez spécifié lors de l'installation initiale (utilisez helm ls pour le retrouver). Si nécessaire, précisez le namespace Kubernetes avec -n (le namespace par défaut est utilisé sinon). Conservez la même version via le flag --version.

Mettre à jour la clé de chiffrement des données PostgreSQL

La rotation de la clé de chiffrement (Django Secret Key) est un processus critique qui implique plusieurs étapes.

attention

La rotation de la clé de chiffrement est un processus intensif qui peut :

• Prendre un temps significatif à se terminer, occupant entièrement un worker Celery.
• Générer une charge de lecture/écriture constante sur la base.
• Augmenter l'usage de l'espace disque de la base (il est recommandé de garantir au moins 5 Go d'espace disque libre).

Installation via KOTS

Le script gitguardian_secret_key.sh vous permet de faire la rotation de la clé de chiffrement de la base.

Prérequis :

• kubectl et la CLI kots (consultez la documentation d'installation).
• Accès au namespace Kubernetes où l'application GitGuardian est installée.

Assurez-vous que ces prérequis sont remplis avant d'exécuter le script.

Installez le script avec la commande suivante :

curl -O https://raw.githubusercontent.com/GitGuardian/ggtools/refs/heads/main/secret-key-rotation/scripts/gitguardian_secret_key.sh
chmod +x gitguardian_secret_key.sh

Le script a deux actions, status et rotate. status affichera les hashs de la ou des clés actuelles, et rotate mettra à jour la configuration.

bash gitguardian_secret_key.sh rotate --namespace <namespace>

Précisez le namespace Kubernetes avec --namespace.

Après la mise à jour de la configuration, le script lancera la console d'administration KOTS où vous devrez déployer la configuration mise à jour.

Installation via Helm

attention

Ne modifiez pas directement les valeurs dans le secret Kubernetes gim-secrets, car ces changements seront écrasés par les mises à niveau Helm suivantes.

1. Générez une nouvelle clé : bien que toute chaîne soit techniquement acceptable, nous conseillons d'utiliser une chaîne longue (minimum 50 caractères) à haute entropie pour une sécurité renforcée.

Mettez à jour le namespace gg_namespace selon vos besoins.

gg_namespace=<namespace>
new_django_key=$(LC_ALL=C tr -dc A-Za-z0-9 </dev/urandom | head -c 50 )
current_key=$(kubectl get secret -n $gg_namespace gim-secrets \
                  -o jsonpath='{.data.DJANGO_SECRET_KEY}' | base64 --decode)
current_encryption_keys=$(kubectl get secret -n $gg_namespace gim-secrets \
              -o jsonpath='{.data.ENCRYPTION_KEYS}' | base64 --decode)

# new encryption starts with new key, that will be used for re-encryption, then current key for fallback
if [ -n "$current_encryption_keys" ]; then
  new_encryption_keys=$(echo -n "$new_django_key,$current_encryption_keys,$current_key")
else
  new_encryption_keys=$(echo -n "$new_django_key,$current_key")
fi

echo "Please set djangoSecretKey with ${new_django_key}"
echo "Please set dbEncryptionKeys with ${new_encryption_keys}"

2. Pour la gestion des secrets, assurez-vous que les mises à jour sont faites au bon endroit selon votre configuration. Regardez votre fichier de values sous la section miscEncryption pour trouver comment le mot de passe est stocké. Pour plus de détails, voir Helm sensitive information management.

• Si vous utilisez un secret manager, modifiez les valeurs requises dedans.
• Si vous utilisez un secret à l'intérieur du namespace, patchez-le :

kubectl patch secret -n $gg_namespace <secret-name> \
    -p "{\"data\":{\"DJANGO_SECRET_KEY\":\"${new_django_key}\"}}"
kubectl patch secret -n $gg_namespace <secret-name> \
    -p "{\"data\":{\"ENCRYPTION_KEYS\":\"${new_encryption_keys}\"}}"

3. Une fois le nouveau mot de passe défini, vous pouvez redéployer l'application :

helm upgrade <release-name> -n <namespace> -f local-values.yaml

Remplacez <release-name> par le nom de release que vous avez spécifié lors de l'installation initiale (utilisez helm ls pour le retrouver). Si nécessaire, précisez le namespace Kubernetes avec -n (le namespace par défaut est utilisé sinon). Conservez la même version via le flag --version.

Initier la rotation de la clé de chiffrement des données

Une fois qu'au moins deux clés de chiffrement sont définies dans vos paramètres :

1. Naviguez jusqu'à la page Encryption Key Rotation dans l'Admin area :

2. Si aucune rotation n'a été initiée pour la clé récemment ajoutée, commencez par déclencher la création des jobs de rotation. Cliquez sur le bouton « Prepare Key Rotation ».

3. Activez les jobs de rotation de clé

attention

Soyez conscient que ces jobs peuvent prendre beaucoup de temps et occuperont entièrement un worker Celery.

4. Les jobs s'exécuteront automatiquement. Il ne reste plus qu'à attendre leur achèvement. Vous avez la possibilité d'arrêter ou de redémarrer les jobs selon vos besoins.