Créer un cluster compatible avec le chiffrement TDE

Sélectionnez une version de la documentation :

L'opérateur Kubernetes AlloyDB Omni automatise le cycle de vie des clusters de chiffrement transparent des données (TDE) à l'aide de la ressource personnalisée TdeConfig. Cette ressource stocke les informations de connexion au service de gestion des clés (KMS), ce qui permet à l'opérateur d'injecter de manière sécurisée les identifiants requis dans les pods de base de données.

Avant de commencer

  • Configurez le moteur de secrets KV-V2 de HashiCorp Vault pour vous assurer que le chemin de la clé de chiffrement de clé (KEK) et le jeton Web JSON (JWT) sont disponibles.
  • Assurez-vous qu'AlloyDB Omni est autorisé à lire le fichier de jeton JWT.

  • Facultatif : Pour déployer un cluster compatible avec le chiffrement TDE sur OpenShift, accordez la contrainte de contexte de sécurité (SCC) hostmount-anyuid au compte de service DBCluster qui exécute le cluster de base de données.

    oc adm policy add-scc-to-user hostmount-anyuid -z DBCLUSTER_NAME-sa -n DBCLUSTER_NAMESPACE

    Remplacez DBCLUSTER_NAME par le nom de DBCluster et DBCLUSTER_NAMESPACE par l'espace de noms dans lequel vous souhaitez créer la ressource DBCluster.

Configurer l'accès au coffre-fort

Créez une ressource secrète contenant votre chemin KEK et vos identifiants d'authentification.

apiVersion: v1
kind: ConfigMap
metadata:
  name: CONFIG_MAP_NAME
data:
  kek_url: "KEK_URL"
  token_path: "JWT_TOKEN_PATH"

Remplacez les éléments suivants :

  • CONFIG_MAP_NAME : nom de la carte de configuration. Les valeurs définies dans kek_url et token_path sont utilisées dans la définition de la ressource TdeConfig.
  • KEK_URL : URL complète de la clé KEK dans HashiCorp Vault. Utilisez vault comme protocole pour spécifier HashiCorp Vault comme fournisseur KMS (par exemple, vault://vault.default.svc:8200/v1/secrets/data/alloydb_kek).
  • JWT_TOKEN_PATH : chemin d'accès au jeton JWT sur le nœud. Exemple : /tmp/token. Le chemin d'accès au jeton JWT doit être cohérent sur tous les nœuds du cluster.

Créer un secret TLS

Pour créer un secret TLS permettant de stocker vos certificats, exécutez les commandes suivantes :

kubectl create secret tls VAULT_SECRET_NAME \
    --cert=vault.crt \
    --key=vault.key

kubectl patch secret VAULT_SECRET_NAME \
    -p '{"data":{"ca.crt":"'$(base64 -w 0 vault.crt)'"}}' \
    --type=merge

Remplacez VAULT_SECRET_NAME par le nom du secret TLS. Vous utiliserez ce nom secret lorsque vous créerez la ressource personnalisée TdeConfig.

Créer la CRD TdeConfig

Créez une ressource TdeConfig qui définit la façon dont AlloyDB Omni communique avec le coffre-fort pour récupérer la clé KEK. Le seul type d'authentification accepté est jwt. Assurez-vous de créer la ressource TdeConfig dans le même espace de noms que la ressource DbCluster.

Assurez-vous que le chemin d'accès à votre jeton JWT est accessible à l'utilisateur postgres et que votre instance Vault est accessible sur le réseau.

Pour créer la ressource TdeConfig, procédez comme suit :

Créez et appliquez un fichier manifeste pour la ressource TdeConfig.

  apiVersion: alloydbomni.dbadmin.goog/v1
  kind: TdeConfig
  metadata:
    name: TDE_CONFIG_NAME
  spec:
    kekUrlRef:
      name: CONFIG_MAP_NAME
      key: kek_url
    kmsProvider:
      vault:
        authType: "jwt"
        authMount: "JWT_AUTH_MOUNT_PATH"
        jwt:
          pathRef:
            name: "CONFIG_MAP_NAME"
            key: "token_path"
          role: "VAULT_ROLE"
    tls:
      certSecret:
        name: "VAULT_SECRET_NAME"

Remplacez les éléments suivants :

  • TDE_CONFIG_NAME : nom de la ressource TdeConfig.
  • JWT_AUTH_MOUNT_PATH : chemin d'accès où le moteur d'authentification est installé dans HashiCorp Vault, tel que défini par votre configuration. Exemple :auth/kms
  • (Facultatif) VAULT_ROLE : rôle client défini dans la configuration de votre coffre-fort. Le rôle client valide le JWT et reflète les droits d'accès et l'identité spécifiques accordés au rôle dans HashiCorp Vault.
  • VAULT_SECRET_NAME : nom du secret contenant les certificats pour la connexion au coffre. Par exemple : vault-secret.

Déployer le DBCluster

  1. Créez et appliquez un fichier manifeste pour créer une ressource DBCluster qui référence votre ressource TdeConfig. Pour en savoir plus sur la création d'un cluster de bases de données, consultez Créer un cluster de bases de données.

    apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: "DBCLUSTER_NAME"
spec:
  databaseVersion: "18.1.0"
  features:
    transparentDataEncryption:
      tdeConfigRef:
        name: "TDE_CONFIG_NAME"

[...]

    Remplacez TDE_CONFIG_NAME par le nom de votre ressource TdeConfig et DBCLUSTER_NAME par le nom de la DBCluster que vous souhaitez créer.

  2. (Facultatif) Si vous déployez DBCluster dans un environnement Openshift, vous devez annoter la ressource DBCluster avec l'annotation hostmount-anyuid.

    kubectl annotate dbclusters.alloydbomni.dbadmin.goog `DBCLUSTER_NAME` -n `DBCLUSTER_NAMESPACE` openshift.io/scc=anyuid

    Remplacez DBCLUSTER_NAME par le nom de votre ressource DBCluster et DBCLUSTER_NAMESPACE par l'espace de noms dans lequel vous souhaitez créer la ressource DBCluster.

Afficher les métriques TDE

Une fois le cluster initialisé, suivez les étapes ci-dessous pour vérifier que le TDE est activé et afficher les métriques TDE associées.

  1. Connectez-vous à votre base de données à l'aide de psql ou du client de votre choix. Pour obtenir des instructions détaillées sur la connexion à vos instances, consultez Exécuter AlloyDB Omni et s'y connecter.

  2. Exécutez la commande suivante :

    select * FROM pgsnap.g$tde_stats;

    Le résultat affiche les métriques TDE, par exemple si TDE est activée, l'URL de la clé de chiffrement de clé, la version de la KEK et l'horodatage de création de la KEK.

    Le tableau suivant explique la signification de chaque métrique.

    Nom Description Libellé Unité Type
    alloydb_omni_database_tde_data_blocks_decrypted_count_total Nombre de blocs de données déchiffrés. Non applicable compteur
    alloydb_omni_database_tde_data_blocks_encrypted_count_total Nombre de blocs de données chiffrés. Non applicable compteur
    alloydb_omni_database_tde_data_decryption_time_us_total Temps total passé à déchiffrer les blocs de données. Non applicable microsecondes compteur
    alloydb_omni_database_tde_data_encryption_time_us_total Temps total passé à chiffrer les blocs de données. Non applicable microsecondes compteur
    alloydb_omni_database_tde_enabled État d'activation du chiffrement transparent des données (TDE). Non applicable jauge
    alloydb_omni_database_tde_kek_info Informations sur le KEK TDE.
    • kek_version : version de la KEK
      utilisée pour l'encapsulation de clé.
    • kek_url : chemin d'accès complet
      à la clé KEK dans KMS
    • kek_creation_timestamp :
      Heure de création de la version de la clé KEK utilisée.
    		 jauge
    alloydb_omni_database_tde_temp_blocks_decrypted_count_total Nombre de blocs temporaires déchiffrés. Non applicable compteur
    alloydb_omni_database_tde_temp_blocks_encrypted_count_total Nombre de blocs temporaires chiffrés. Non applicable compteur
    alloydb_omni_database_tde_temp_decryption_time_us_total Temps total passé à déchiffrer les blocs temporaires. Non applicable microsecondes compteur
    alloydb_omni_database_tde_temp_encryption_time_us_total Temps total passé dans le chiffrement de bloc temporaire. Non applicable microsecondes compteur
    alloydb_omni_database_tde_wal_blocks_decrypted_count_total Nombre de blocs WAL déchiffrés. Non applicable compteur
    alloydb_omni_database_tde_wal_blocks_encrypted_count_total Nombre de blocs WAL chiffrés. Non applicable compteur
    alloydb_omni_database_tde_wal_decryption_time_us_total Temps total passé à déchiffrer les blocs WAL. Non applicable microsecondes compteur
    alloydb_omni_database_tde_wal_encryption_time_us_total Temps total passé à chiffrer les blocs WAL. Non applicable microsecondes compteur