La gestion des secrets dans Google Cloud Platform

Dans cet article nous allons voir comment gérer nos secrets dans GCP, pour cela nous verrons 2 outils. Tout d’abord  KMS (Key Management Service), qui permet de gérer un système de trousseau de clés. Puis, un nouvel outil qui est en version bêta sur GCP : Secret Manager (Si vous utilisez AWS, le principe de KMS et Secrets Manager sont les mêmes).

Voici les définitions des deux services :

Cloud KMS chiffre les données et renvoie ces données chiffrées. Le service ne stocke pas le secret, seulement les clés pour chiffrer/déchiffrer.

Secret Manager stocke le secret. Il conserve également un historique des versions du secret. À l'heure actuelle, Secret Manager chiffre les données avec une clé gérée par Google. À l'avenir, les utilisateurs pourront chiffrer les données à l'aide de leurs propres clés.

Comment fonctionnent KMS et Secret Manager

Cloud KMS est conçu comme un système cryptographique : personne, ni nous-même, ne pouvons retirer les clés. Cela signifie qu'elles sont verrouillées à l'intérieur du système et que nous n'avons pas à nous soucier en pratique de leur fuite. Le compromis est que la seule chose que nous pouvons faire avec ces clés est le chiffrement et déchiffrement. Si nous avons un mot de passe de base de données ou autre chose que nous souhaitons garder secret, afin de l’utiliser ou de l’envoyer ailleurs, nous devons stocker la version chiffrée, puis utiliser Cloud KMS pour la déchiffrer.
Lorsque nous avons des informations de configuration comme un mot de passe de base de données, Secret Manager est là pour nous.

Cas d’utilisation de KMS :

• Chiffrement du contenu de la base de données
• Chiffrement d’image
• Chiffrement de fichier
• Chiffrement de backup
• etc...

KMS est très utile pour chiffrer de gros contenu.

Cas d’utilisation de Secret manager :

• Chiffrement de token
• Chiffrement d’une API key
• Chiffrement de donnée sensible (mot de passe)
• etc...

Secret Manager est parfaitement adapté pour les petites quantité de données.

En pratique

Nous allons maintenant voir comment créer les ressources pour KMS et Secret Manager aussi bien dans la console GCP que par Terraform.
Nous verrons, ensuite, comment utiliser la clé de chiffrement KMS pour chiffrer/déchiffrer un secret, ou récupérer le secret qui est stocké dans Secret Manager. Enfin, nous nous intéresserons au cas spécifique de la création d’un secret Kubernetes.

KMS

Pour débuter, mettons KMS en pratique :

Console :

Pour aller sur KMS dans la console GCP, nous allons nous diriger vers deux endroits : dans la section “Security” ou dans la section “IAM” et ensuite aller sur “Cryptographic Keys”.

En allant sur Cryptographic keys, la console GCP va nous amener directement sur la page d’activation de l’API KMS.

Directement après l’activation de l’API, nous allons créer un trousseau de clés et sa clé associé.

La première étape est de créer le trousseau de clés, dans mon exemple, je l’ai nommé “my-keyring” dans la région “europe-west1”.

Maintenant que le trousseau de clés est créé, nous pouvons créer la clé associée à ce trousseau, et définir si nous souhaitons que la clé soit :

• générée
• importée
• managée externe

Restons sur la solution par défaut, c'est-à-dire sur une clé générée. Pour le chiffrement nous laissons une protection software et non hardware, et partons sur un chiffrement/déchiffrement symétrique avec une rotation de la clé tous les 90 jours.

Et voilà, nous avons notre trousseau de clés et sa clé associée qui nous permettra de chiffrer/déchiffrer avec KMS.

Terraform :

Comme nous le savons faire les choses dans la console c’est bien, mais le faire en Infrastructure as code c’est encore mieux ! On va donc utiliser Terraform pour faire toutes ces actions. Pour la partie Terraform nous avons utilisé la version 0.12.23 de l’outil.

Warning : Bien que ce code illustre comment déclarer l'utilisation de ces services avec Terraform, son application stockera une copie décodée de notre secret dans le tfstate obligeant à le sécuriser au même titre que le secret lui-même (voici les quelques recommandations concernant les données sensibles dans Terraform : https://www.terraform.io/docs/state/sensitive-data.html)

Création du trousseau de clés :

resource "google_kms_key_ring" "kms-keyring" {
  project  = sandbox-wescale
  name     = "my-keyring"
  location = "europe-west1"

  lifecycle {
    prevent_destroy = true
  }
}

Création d’une clé sur le trousseau “my-keyring” :

resource "google_kms_crypto_key" "kms-key" {
  name     = my-key
  key_ring = google_kms_key_ring.kms-keyring.self_link
  purpose  = "ENCRYPT_DECRYPT"
  version_template {
    algorithm = "GOOGLE_SYMMETRIC_ENCRYPTION"
  }
}

Cette partie va permettre de déchiffrer via la clé KMS et de la réutiliser dans votre code Terraform. Le ciphertext que vous voyez ci-dessous est un secret que nous avons chiffré via KMS. On peut aussi passer des fichiers directement si nous le souhaitons.

data "google_kms_secret" "ecom_secret_k8s" {
  crypto_key = google_kms_crypto_key.kms-key.self_link
  ciphertext = "CiQAqD+xX4SXOSziF4a8JYvq4spfAuWhhYSNul33H85HnVtNQW4SOgDu2UZ46dQCRFl5MF6ekabviN8xq+F+2035ZJ85B+xTYXqNf4mZs0RJitnWWuXlYQh6axnnJYu3kDU="
}

Voici une des utilisations d’un secret déchiffré par KMS dans un exemple de code Terraform (la configuration du provider pour kubernetes a été omise par simplicité) :

resource "kubernetes_secret" "secret-test" {
  metadata {
    name        = "secret-test"
    namespace   = test
  }

  data = {
    "data"     = data.google_kms_secret.sql_user_password.plaintext
  }
}

Si nous voulons supprimer la ressource via Terraform, elle disparaîtra de votre terraform.tfstate. Par contre la ressource sera toujours existante sur votre projet GCP (même une demande au support de Google pour la suppression du keyring est impossible). Le seul moyen de supprimer un trousseau de clés est de supprimer le projet, donc soyez vigilants : ne le créez pas sur un projet important, sinon vous devrez le garder ad vitam æternam.

Si nous voulons chiffrer/déchiffrer un secret avec KMS via gcloud il suffit d’utiliser les commandes suivantes :

Commande pour chiffrer un objet avec KMS :

gcloud kms encrypt --project sandbox-wescale \
--location europe-west1 \
--keyring kms-keyring \
--key kms-key \
--plaintext-file <name of file to contain the crypted secret> \
--ciphertext-file <name of file to contain the crypted secret>

Commande pour déchiffrer un objet avec KMS :

gcloud kms decrypt --project sandbox-wescale \
--location europe-west1 \
--keyring kms-keyring \
--key kms-key \
--plaintext-file <name of file to contain the crypted secret> \
--ciphertext-file <name of file to contain the crypted secret>

Secret Manager

Console :

Comme dans KMS nous allons dans la partie “Security” de la console GCP et cette fois,sur la partie Secret Manager.

Il faut aussi activer l’API de Secret Manager.

Passée l’activation de l’API de Secret Manager, nous pouvons créer notre secret.

Nous arrivons sur la fenêtre de création de notre secret avec son nom. Nous avons la possibilité de mettre une valeur texte ou un fichier. La valeur peut être chiffrée auparavant, il faudra juste la déchiffrer en la récupérant plus tard.

Il faut savoir que nous pouvons sélectionner plusieurs régions, et si cela n’est pas fait, Google choisira la meilleure région pour nous.

Notre secret peut contenir plusieurs versions. Nous avons la possibilité de voir directement sa valeur, de le désactiver (ce qui désactivera sa facturation), de le détruire et de copier l’ID de la ressource.

Terraform :

Après avoir vu l’utilisation de Secret manager à la console, répétons l’exercice en Infrastructure As Code à l’aide de Terraform.

Warning : Bien que ce code illustre comment déclarer l'utilisation de ces services avec Terraform, son application stockera une copie décodée de notre secret dans le tfstate obligeant à le sécuriser au même titre que le secret lui-même (voici les quelques recommandations concernant les données sensibles dans Terraform : https://www.terraform.io/docs/state/sensitive-data.html)

resource "google_secret_manager_secret" "secret-basic" {
  provider = google-beta
  project  = var.project

  secret_id = "secret"

  replication {
    user_managed {
      replicas {
        location = "europe-west1"
      }
    }
  }
}

resource "google_secret_manager_secret_version" "secret-version-basic" {
  provider = google-beta

  secret = google_secret_manager_secret.secret-basic.id

  secret_data = "secret-data"
}

Récupération du secret “my-secret” via le datasource Terraform :

data "google_secret_manager_secret_version" "basic" {
  provider = google-beta
  secret = "my-secret"
}

Il suffit d'appeler data.google_secret_manager_secret_version.basic.secret_data. Si nous reprenions le même exemple que pour KMS pour le secret kubernetes, cela nous donnera l’exemple suivant (comme pour la partie KMS, la configuration du provider pour kubernetes a été omise par simplicité) :

resource "kubernetes_secret" "secret-test" {
  metadata {
    name        = "secret-test"
    namespace   = test
  }

  data = {
    "data"     = data.google_secret_manager_secret_version.basic.secret_data
  }
}

Si nous souhaitons récupérer le secret via gcloud, voici la commande qui permet d'accéder à une version spécifique du secret :

$ gcloud secrets versions access 1 --secret="my-secret"

Et voici celle qui permet d'accéder à la dernière version du secret :

$ gcloud secrets versions access latest --secret="my-secret"

Et la tarification dans tout ça ?

Côté Secret Manager :

L'utilisation de Secret Manager entraîne des frais pour les opérations et les versions actives des secrets. Une version est active si elle présente l'état ENABLED ou DISABLED.

Côté KMS :

Les clés asymétriques et les clés symétriques sont disponibles au même tarif pour la partie KMS.

Quelles sont les différences de tarification entre KMS et Secret Manager :

Il y a quand même une petite différence de prix entre KMS et Secret Manager. Par exemple (pour la comparaison en se basant sur une clé symétrique dotée du niveau de protection logiciel pour KMS) :

Pour Secret Manager le prix sera de 0,06 €  par secret, et pareil côté KMS, nous paierons 0,06 € par clé de chiffrement.

Vous allez me dire : “oui c’est pareil”, mais non... Car nous avons une seule clé de chiffrement pour 100 secrets par exemple avec KMS, ce qui donnera une facturation à 0,06 €  pour nos secrets via KMS.

Tandis qu’avec Secret Manager si nous avons 100 secrets, le prix sera de 0,06 € par secret donc 0,06 *100, ce qui nous donnera une facturation de 6 euros par mois pour tous les secrets. L’un dans l’autre, les deux services restent économique pour leur utilité.

Conclusion :

Secret Manager est une très bonne alternative à KMS, il permet de ne pas gérer le trousseau de clés et la clé de chiffrement. nous ne sommes plus obligés de chiffrer nos secrets à la main, cela offre plus de simplicité, surtout pour des secrets qui concernent uniquement des API tokens, mots de passe, etc… .

Vous souhaitez monter en compétence sur Google Cloud Platform ?

Nos experts vous proposent  une formation sur le sujet.

Inscrivez-vous vite sur training@wescale.fr les places sont limitées !