## Intro Apache NiFi est facile à démarrer dans un conteneur, mais l'exécuter de manière sécurisée en production nécessite une configuration délibérée du chiffrement du transport (TLS (Transport Layer Security) : protocole de chiffrement standard), de l'authentification, de l'autorisation et de la gestion des secrets. Ce guide s'adresse aux développeurs, ingénieurs DevOps et équipes techniques de startups qui ont besoin d'un processus de durcissement répétable et vérifiable qu'ils peuvent exécuter localement avant de le promouvoir vers CI/CD (Continuous Integration/Continuous Deployment) : intégration continue/déploiement continu ou un environnement de type production. L'article parcourt quatre phases concrètes : identifier les ressources de sécurité, appliquer la configuration, vérifier le résultat avec une seule commande et observer le mode de défaillance en cas de mauvaise configuration. Chaque phase inclut un exemple minimal et exécutable pour que vous puissiez confirmer le comportement sur votre propre machine. ## Workflow Overview 1. Identifier les ressources – La sécurité de NiFi repose sur trois fichiers : - conf/keystore.jks – certificat serveur et clé privée pour HTTPS. - conf/truststore.jks – certificats CA (Certificate Authority) : autorité de certification de confiance pour l'authentification client. - conf/authorizers.xml – définit les fournisseurs utilisateur‑groupe, les politiques d'accès et l'implémentation de l'autorisateur. JKS (Java KeyStore) : format de magasin de clés Java. 2. Appliquer la configuration – Modifier conf/nifi.properties pour pointer vers le keystore/truststore et activer l'autorisateur : nifi.security.keystore=./conf/keystore.jks nifi.security.keystoreType=JKS nifi.security.keystorePasswd=changeit nifi.security.keyPasswd=changeit nifi.security.truststore=./conf/truststore.jks nifi.security.truststoreType=JKS nifi.security.truststorePasswd=changeit nifi.security.needClientAuth=true nifi.web.https.host=0.0.0.0 nifi.web.https.port=8443 nifi.security.user.authorizer=managed-authorizer nifi.security.user.login.identity.provider=single-user-provider 3. Vérifier la configuration – Démarrer NiFi et interroger le point de terminaison REST (Representational State Transfer) : style d'architecture avec curl en utilisant le truststore : ./bin/nifi.sh start sleep 10 curl --cacert conf/truststore.jks --cert conf/keystore.jks:changeit https://localhost:8443/nifi-api/flow/about Une réponse réussie retourne du JSON avec la version NiFi et l'horodatage de construction. 4. Observer l'échec – Modifier nifi.security.keystorePasswd avec une valeur incorrecte, redémarrer NiFi et répéter la commande curl . La commande restera bloquée ou renverra curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL , indiquant que le keystore ne peut pas être ouvert. Ce retour immédiat prouve que la configuration est appliquée. ## Local Pilot Plan Créez un répertoire de travail propre et exécutez les étapes suivantes à partir d'un checkout frais. Toutes les commandes sont à usage unique et peuvent être copiées dans un script shell pour la répétabilité. mkdir -p nifi-hardening && cd nifi-hardening # 1. Télécharger le binaire NiFi 2.2.0 wget -q https://archive.apache.org/dist/nifi/2.2.0/nifi-2.2.0-bin.tar.gz tar -xzf nifi-2.2.0-bin.tar.gz cd nifi-2.2.0 # 2. Générer un keystore et un truststore auto‑signés keytool -genkeypair -alias nifi -keyalg RSA -keysize 2048 -keystore conf/keystore.jks -storepass changeit -keypass changeit -dname "CN=localhost, OU=Dev, O=Example, L=City, ST=State, C=US" -ext "SAN=dns:localhost,ip:127.0.0.1" -validity 365 keytool -exportcert -alias nifi -keystore conf/keystore.jks -storepass changeit -file nifi.crt keytool -importcert -alias nifi -file nifi.crt -keystore conf/truststore.jks -storepass changeit -noprompt # 3. Appliquer les modifications de propriétés indiquées dans Workflow Overview cat > conf/nifi.properties <<'EOF' nifi.security.keystore=./conf/keystore.jks nifi.security.keystoreType=JKS nifi.security.keystorePasswd=changeit nifi.security.keyPasswd=changeit nifi.security.truststore=./conf/truststore.jks nifi.security.truststoreType=JKS nifi.security.truststorePasswd=changeit nifi.security.needClientAuth=true nifi.web.https.host=0.0.0.0 nifi.web.https.port=8443 nifi.security.user.authorizer=managed-authorizer nifi.security.user.login.identity.provider=single-user-provider EOF # 4. Démarrer NiFi et vérifier ./bin/nifi.sh start sleep 12 curl --cacert conf/truststore.jks --cert conf/keystore.jks:changeit https://localhost:8443/nifi-api/flow/about Test d'échec – Introduire une faute de frappe dans le mot de passe du keystore et redémarrer : sed -i 's/nifi.security.keystorePasswd=changeit/nifi.security.keystorePasswd=wrong/' conf/nifi.properties ./bin/nifi.sh restart sleep 10 curl --cacert conf/truststore.jks --cert conf/keystore.jks:changeit https://localhost:8443/nifi-api/flow/about La commande curl échouera avec une erreur de handshake SSL, confirmant que NiFi refuse de démarrer lorsque le keystore ne peut pas être déverrouillé. ## Conclusion Durcir NiFi n'est pas un exercice de copier‑coller unique. Traitez chaque artefact de sécurité — keystore, truststore, authorizers.xml et le fichier de propriétés — comme un composant testable. Exécutez la commande de vérification après chaque modification et cassez délibérément un paramètre pour observer le mode de défaillance. Cette habitude rend la configuration visible, répétable et sûre à promouvoir dans les pipelines CI/CD (Continuous Integration/Continuous Deployment) : intégration continue/déploiement continu. Prochaines étapes pour un déploiement en production : - Remplacer les certificats auto‑signés par des certificats signés par une CA (Certificate Authority) : autorité de certification et mettre à jour le truststore en conséquence. - Externaliser les mots de passe à l'aide de variables d'environnement ou d'un gestionnaire de secrets (par exemple HashiCorp Vault) et les référencer dans nifi.properties avec ${VAULT_PASSWORD} . - Définir des politiques d'accès à grain fin dans authorizers.xml pour les équipes multi‑locataires. - Automatiser le script de pilotage local dans votre pipeline CI afin que chaque pull request prouve la ligne de base de sécurité avant la fusion. En maintenant la boucle de vérification serrée et les signaux d'échec évidents, vous évitez les surprises lorsque la même instance NiFi durcie s'exécute en staging ou en production.