Database Security

Maintenir la sécurité de vos systèmes de base 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 de données 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 attentivement ces procédures pour renforcer la posture de sécurité de vos bases de données.

Mettre à jour le mot de passe PostgreSQL

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

attention

Veillez à sauvegarder votre base de données avant de commencer cette procédure, qui entraînera une indisponibilité minimale de l'application — du scale down jusqu'au redéploiement complet.

1. Réduisez l'échelle (scale down) du Dashboard, de la Public API et des récepteurs de webhook.

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

Si nécessaire, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé s'il n'est pas spécifié).

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 doit indiquer - empty - pour chaque pod, signalant la fin de l'exécution.

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 l'échelle (scale down) de tous les pods workers et scheduler.

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

Si nécessaire, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé s'il n'est pas spécifié).

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. Une fois votre environnement configuré, 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 basée sur KOTS

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

Installation basée sur Helm

attention

Ne modifiez pas directement les valeurs dans le secret Kubernetes gim-secrets, car de telles modifications seront écrasées par les mises à niveau Helm ultérieures.

1. Pour la gestion des secrets, assurez-vous que les mises à jour sont effectuées à l'emplacement approprié en fonction de votre configuration. Consultez votre fichier de valeurs dans la section postgresql pour savoir comment le mot de passe est stocké. Pour plus de détails, consultez Gestion des informations sensibles Helm.

• Si vous utilisez un gestionnaire de secrets, modifiez-y les valeurs requises.
• Si vous utilisez un secret à l'intérieur du namespace, appliquez-lui un patch :

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 trouver). Si nécessaire, spécifiez le namespace Kubernetes avec -n (le namespace par défaut est utilisé s'il n'est pas spécifié). Conservez la même version à l'aide de l'indicateur --version.

Mettre à jour le mot de passe principal Redis (external cluster)

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

• Installation Redis standard : créez une nouvelle instance avec des paramètres identiques ou mettez directement à jour 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 instructions de Rotate AUTH token.
• GCP Memorystore : modifiez la chaîne AUTH en basculant AUTH de off à on.
• Chart Helm Bitnami : dans le fichier de valeurs du Chart Helm Redis, modifiez la valeur global.redis.password avec le nouveau mot de passe. Appliquez les modifications avec helm upgrade <redis-release> -f <redis-values.yaml>.

Installation basée sur KOTS

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

Installation basée sur Helm

attention

Ne modifiez pas directement les valeurs dans le secret Kubernetes gim-secrets, car de telles modifications seront écrasées par les mises à niveau Helm ultérieures.

1. Pour la gestion des secrets, assurez-vous que les mises à jour sont effectuées à l'emplacement approprié en fonction de votre configuration. Consultez votre fichier de valeurs dans la section redis.main pour savoir comment le mot de passe est stocké. Pour plus de détails, consultez Gestion des informations sensibles Helm.

• Si vous utilisez un gestionnaire de secrets, modifiez-y les valeurs requises.
• Si vous utilisez un secret à l'intérieur du namespace, appliquez-lui un patch :

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 trouver). Si nécessaire, spécifiez le namespace Kubernetes avec -n (le namespace par défaut est utilisé s'il n'est pas spécifié). Conservez la même version à l'aide de l'indicateur --version.

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

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, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé s'il n'est pas spécifié).

Mettre à jour le certificat client PostgreSQL (external cluster)

info

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

attention

Veillez à sauvegarder votre base de données avant de commencer cette procédure, qui entraînera une indisponibilité minimale de l'application — du scale down jusqu'au redéploiement complet.

1. Réduisez l'échelle (scale down) du Dashboard, de la Public API et des récepteurs de webhook.

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

Si nécessaire, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé s'il n'est pas spécifié).

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 doit indiquer - empty - pour chaque pod, signalant la fin de l'exécution.

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 l'échelle (scale down) de tous les pods workers et scheduler.

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

Si nécessaire, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé s'il n'est pas spécifié).

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 basée sur KOTS

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

Installation basée sur Helm

attention

Ne modifiez pas directement les valeurs dans le secret Kubernetes gim-secrets, car de telles modifications seront écrasées par les mises à niveau Helm ultérieures.

1. Pour la gestion des secrets, assurez-vous que les mises à jour sont effectuées à l'emplacement approprié en fonction de votre configuration. Consultez votre fichier de valeurs dans la section postgresql pour savoir comment le mot de passe est stocké. Pour plus de détails, consultez Gestion des informations sensibles Helm.

• Si vous utilisez un gestionnaire de secrets, modifiez-y les valeurs requises.
• Si vous utilisez un secret à l'intérieur du namespace, appliquez-lui un patch :

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, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé s'il n'est pas spécifié).

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 trouver). Si nécessaire, spécifiez le namespace Kubernetes avec -n (le namespace par défaut est utilisé s'il n'est pas spécifié). Conservez la même version à l'aide de l'indicateur --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 beaucoup de temps à se terminer, occupant entièrement un worker Celery.
• Générer une charge constante en lecture/écriture sur la base de données.
• Augmenter l'utilisation de l'espace disque de la base de données (il est recommandé de s'assurer d'avoir au moins 5 Go d'espace disque libre).

Installation basée sur KOTS

Le script gitguardian_secret_key.sh vous permet d'effectuer la rotation de la clé de chiffrement de la base de données.

Prérequis :

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

Assurez-vous que ces exigences sont remplies avant d'exécuter le script.

Installez le script à l'aide de 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 dispose de deux actions, status et rotate. status affichera les hachages de la ou des clés actuelles, et rotate mettra à jour la configuration.

bash gitguardian_secret_key.sh rotate --namespace <namespace>

Spécifiez le namespace Kubernetes avec --namespace.

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

Installation basée sur Helm

attention

Ne modifiez pas directement les valeurs dans le secret Kubernetes gim-secrets, car de telles modifications seront écrasées par les mises à niveau Helm ultérieures.

1. Générez une nouvelle clé : Bien que n'importe quelle 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 effectuées à l'emplacement approprié en fonction de votre configuration. Consultez votre fichier de valeurs dans la section miscEncryption pour savoir comment le mot de passe est stocké. Pour plus de détails, consultez Gestion des informations sensibles Helm.

• Si vous utilisez un gestionnaire de secrets, modifiez-y les valeurs requises.
• Si vous utilisez un secret à l'intérieur du namespace, appliquez-lui un patch :

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 trouver). Si nécessaire, spécifiez le namespace Kubernetes avec -n (le namespace par défaut est utilisé s'il n'est pas spécifié). Conservez la même version à l'aide de l'indicateur --version.

Lancer 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 vers la page Encryption Key Rotation dans l'Admin area :

2. Si aucune rotation n'a été lancé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

Sachez 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.