Utiliser les ConfigMaps Kubernetes en toute sécurité

Les ConfigMaps sont des objets d’API utilisés dans Kubernetes pour stocker des données sous forme de paires clé-valeur. Il s’agit essentiellement de dictionnaires contenant des paramètres de configuration. Une ConfigMap peut notamment contenir des noms d’hôte, des identifiants publics, des chaînes de connexion et des URL.

Une ConfigMap dissocie le code d’une application de sa configuration, ce qui permet de modifier celle-ci sans affecter l’application. Elle permet, par exemple, de définir des configurations différentes pour les environnements de développement, de test et de production.

Toutefois, l’utilisation des ConfigMaps peut présenter des risques de sécurité, car elles ne chiffrent pas les données qu’elles contiennent. Il est donc important de savoir quand les utiliser et dans quels cas elles ne sont pas suffisamment sécurisées.

Cet article explique le fonctionnement des ConfigMaps, comment les utiliser en toute sécurité et dans quels cas privilégier d’autres solutions de stockage des données, plus sécurisées.

Les ConfigMaps dans Kubernetes

Avant de voir comment utiliser les ConfigMaps, examinons leurs détails techniques et leur rôle dans Kubernetes.

Fonctionnement des ConfigMaps

Les ConfigMaps stockent des paires clé-valeur sous forme de données textuelles ou binaires, contrairement aux autres objets Kubernetes qui utilisent des champs spec. Elles peuvent stocker des données binaires sous forme de chaînes encodées en base64 et des données textuelles sous forme de séquences d’octets UTF-8.

Le cluster peut accéder aux ConfigMaps de plusieurs façons :

• En les montant comme volume de données.

• En y accédant à distance depuis des pods appartenant au même espace de noms Kubernetes.

• En les séparant des pods pour permettre à d’autres composants du cluster Kubernetes de les utiliser.

Les pods peuvent utiliser les ConfigMaps comme fichiers de configuration, variables d’environnement ou arguments de ligne de commande.

Lorsque vous utilisez des ConfigMaps, gardez à l’esprit que leur taille est limitée à 1 Mo. Pour des jeux de données plus volumineux, envisagez d’autres solutions de stockage, comme des bases de données, des montages de fichiers distincts ou des services de fichiers.

Le rôle des ConfigMaps

Le rôle le plus important des ConfigMaps est de rendre les applications portables en séparant le code de l’application des paramètres de configuration. Cette séparation facilite la migration d’un environnement de développement vers un environnement de test, puis vers un environnement de production.

Prenons un exemple d’utilisation d’une ConfigMap dans Kubernetes. Imaginons que nous développions une application en local et souhaitions la déployer auprès d’un fournisseur de service Kubernetes managé.

Pour accéder à la base de données en local, nous devons définir la variable d’environnement DATABASE_HOST sur localhost ou 127.0.0.1. Lors du passage en production, nous devons modifier la valeur de cette variable pour désigner l’adresse qui expose le composant de base de données.

Utiliser les ConfigMaps en toute sécurité

Avant de commencer, voici les prérequis pour créer une ConfigMap dans un cluster Kubernetes local :

• La dernière version de Docker Desktop

• Minikube

• Kubectl

• Un éditeur de code, comme VS Code.

Dans cette démonstration, nous allons créer une ConfigMap en YAML et la monter comme volume. Cette méthode permet de la créer comme n’importe quelle ressource Kubernetes.

Créez un fichier nommé mongo-config.yaml et ajoutez le code suivant :

1kind: ConfigMap
2apiVersion: v1
3metadata:
4  name: test-configmap
5data:
6  # Setting the configuration as key-value properties
7  database: mongodb
8  database_uri: mongodb://localhost:8080
9keys: |
10  image.public.key=554
11  rsa.public.key=36

Créez ensuite une ConfigMap à partir du fichier ci-dessus à l’aide de la commande suivante :

1kubectl apply -f mongo-config.yaml

Voyons maintenant comment utiliser la ConfigMap. Cette démonstration utilise celle créée ci-dessus avec des variables d’environnement. Pour l’utiliser, ajoutez une propriété envFrom au YAML du pod, comme dans le code ci-dessous :

1kind: Pod
2apiVersion: v1
3metadata:
4  name: pod-variables-env
5spec:
6  containers:
7    - name: configmap-var
8      image: nginx:1.7.9
9      envFrom:
10        - configMapRef:
11          name: test-configmap

Dans l’extrait de code ci-dessus, nous avons utilisé envFrom pour accéder aux informations de la ConfigMap depuis un conteneur.

Dernière étape : associez-la aux pods en exécutant la commande ci-dessous :

1kubectl exec -it pod-variables-env sh

La ConfigMap est ainsi mise à la disposition des conteneurs sous forme de variable d’environnement.

Les Secrets dans Kubernetes

Les Secrets sont souvent présentés comme des alternatives sécurisées aux ConfigMaps, car ils ont plusieurs points communs :

• Ils utilisent des paires clé-valeur pour stocker les données.

• Les pods peuvent les utiliser comme fichiers dans un volume.

• Ils peuvent être utilisés comme variables d’environnement (même si ce n’est pas recommandé).

• Ce sont des types d’objets accessibles via un serveur d’API.

• Ils sont tous deux limités à 1 Mo et ne conviennent donc pas au stockage de données volumineuses.

Les Secrets sont des objets conçus pour chiffrer et stocker des données confidentielles dans Kubernetes. Ils permettent notamment de stocker des mots de passe, des clés d’API, des jetons et des chaînes de connexion aux bases de données. Ils séparent ainsi les données sensibles du code de l’application. Cette séparation réduit le risque d’exposition de données sensibles, qui pourrait mettre en péril le cluster et l’application. Évitez d’utiliser les Secrets pour les variables d’environnement. Comme l’expliquent Liz Rice et Michael Hausenblasbokk dans leur livre Kubernetes Security :

• les variables d’environnement sont souvent consignées dans les journaux en cas de plantage ou d’erreur

• kubectl describe pod expose les valeurs des variables d’environnement en clair

• docker inspect expose les valeurs des variables d’environnement en clair

Il existe plusieurs types de Secrets, à choisir selon les données que vous souhaitez garder confidentielles. Le type le plus couramment utilisé est Opaque, qui permet de stocker des données arbitraires définies par l’utilisateur. Pour l’authentification de base, utilisez le type basic-auth.

Par défaut, les Secrets ne sont pas chiffrés et sont stockés dans etcd, le magasin de données du serveur d’API. Toute personne ayant accès à l’API peut consulter et modifier les Secrets. Pour en restreindre l’accès, vous devez :

• Activer le chiffrement des données des Secrets au repos (de nombreux fournisseurs Kubernetes managés, voire tous, proposent cette option lors de la création du cluster).

• Activer et configurer les règles RBAC pour limiter la lecture et la modification.

• Limiter la création de Secrets à l’aide de RBAC.

ConfigMaps et Secrets

Bien que les ConfigMaps et les Secrets présentent des similitudes, ils sont différents et répondent chacun à des cas d’utilisation spécifiques, selon vos besoins en matière de sécurité.

La principale différence entre les ConfigMaps et les Secrets concerne la confidentialité des données qu’ils contiennent. Les Secrets masquent les données par encodage base64, tandis que les ConfigMaps stockent les données en texte clair. Notez qu’il est également possible de stocker dans une ConfigMap du texte clair sous forme de chaînes encodées en base64.

Autre différence : Kubernetes propose plusieurs types de Secrets. Vous pouvez choisir le type adapté aux données sensibles que vous souhaitez protéger.

Quand utiliser les ConfigMaps

Les ConfigMaps permettent de séparer efficacement les données de l’application du code de configuration. Supposons, par exemple, que nous ayons un conteneur d’application qui gère les données des employés et se connecte à une base de données MySQL. Si nous intégrons directement la configuration de connexion à la base de données dans le conteneur, le passage d’un environnement de développement à un environnement de production risque de poser problème : nous ne pouvons pas utiliser la base de données de développement en production.

Une ConfigMap facilite le déploiement de l’application en stockant les données de configuration dans un fichier séparé, en dehors du conteneur. Pour changer d’environnement, il suffit alors de modifier la référence à la base de données.

Affichez facilement les données d’une ConfigMap en exécutant kubectl describe configmaps <name>. Vous pouvez également modifier ces données facilement, puisqu’elles sont en texte clair. Ces caractéristiques facilitent l’adaptation de la configuration à l’environnement (développement, test ou production), mais rendent les ConfigMaps inadaptées au traitement de données sensibles. Stockez ces dernières dans des Secrets Kubernetes afin qu’elles puissent être chiffrées et que leur accès soit limité.

Quand utiliser les Secrets

Comme les ConfigMaps, les Secrets dissocient les données du code de l’application. Ils permettent d’éviter l’exposition de données sensibles lors de la création ou de la modification d’un pod.

Reprenons l’exemple des données des employés. Dans ce cas, l’application a besoin d’un nom d’hôte de serveur, d’un port, du nom de la base de données, d’un nom d’utilisateur et d’un mot de passe pour s’y connecter.

Comparons deux extraits de code. Le premier montre comment une ConfigMap gère les données, et le second, comment un Secret les gère.

Voici à quoi ressemble une ConfigMap :

1db-configmap.yaml
2
3apiVersion: v1
4kind: ConfigMap
5# ConfigMap data
6metadata:
7  name: employee-database-conf
8  namespace: default
9# Database configurations
10data:
11  server.host: "10.07.11.653"
12  server.port: "3030"
13  db.name: employees_data

Le fichier YAML de ConfigMap ci-dessus contient les détails non sensibles de la connexion à la base de données : nom d’hôte du serveur, port du serveur et nom de la base de données.

Voici à quoi ressemblerait un fichier Secret :

1db-secret.yaml
2
3apiVersion: v1
4kind: Secret
5# Secret Data
6metadata:
7  name: employee-database-auth
8  namespace: default
9# The type of Secret 
10type: kubernetes.io/basic-auth
11# Secret data
12stringData:
13  username: dGhlYWRtaW4= //theadmin
14  password: YWRtaW5wYXNz //adminpass

Dans le fichier YAML Secret ci-dessus, le type de Secret est défini sur basic-auth, qui gère les identifiants d’authentification de base. Le champ stringData contient les données à garder confidentielles, en l’occurrence le nom d’utilisateur et le mot de passe.

Dans cet exemple hypothétique, les Secrets nous ont permis de garder confidentiels le nom d’utilisateur et le mot de passe de la base de données. Ils éliminent également le risque d’exposer ces informations lors de la création ou de la modification du pod.

Sécurité de la configuration Kubernetes

Une ConfigMap est un objet d’API Kubernetes qui stocke des données de configuration non sensibles sous forme de paires clé-valeur. Par défaut, les données sont stockées en texte clair, ce qui permet de séparer le code de l’application de sa configuration. Les Secrets sont également des objets d’API Kubernetes, utilisés pour chiffrer et stocker des données de configuration sensibles sous forme de paires clé-valeur. Ils réduisent toutefois le risque d’exposition de ces données, qui pourrait mettre en péril le cluster et l’application.

Pour créer un cluster Kubernetes sécurisé qui sépare le code de l’application de sa configuration, stockez les données sensibles dans des Secrets et les configurations non sensibles dans des ConfigMaps. Veillez également à activer RBAC pour restreindre l’accès aux ConfigMaps et aux Secrets. Vous réduirez ainsi le risque d’accès ou de modification non autorisés de la configuration.