environnement de production pour le printemps Nuage Config utilisant Git/Vault

Question

Spring Boot - 2.0.0.M3 nuage de printemps - Finchley.M1

Je veux savoir si quelqu'un utilise le serveur de configuration Spring Cloud à la fois voûte et soutien git dans une configuration de production utilisant le backend de stockage de base de données. J'ai évalué Spring config cloud en utilisant le coffre-fort et je me demandais si je devais utiliser Oracle JCE pour chiffrer le nom d'utilisateur/pwd ou Vault et chercher des suggestions sur le même. nous travaillons sur Springboot/microservices.

Voici mes conclusions -

1. Vault introduira une couche supplémentaire et donc introduira usecases de sécurité supplémentaires, d'audit tout en communiquant avec Vault. Printemps cloud Les extrémités des actionneurs de configuration sont interrompues pour la génération des jalons à ce stade pour la génération de valeurs cryptées et/encrypt/decrypt peut ne pas fonctionner si nous optons pour le support Oracle JCE afin de générer des valeurs cryptées via des versions stables. Nous ne souhaitons pas utiliser le serveur consul et essayons d'utiliser Cassandra comme serveur de stockage. J'ai utilisé le backend d'authentification Vault à l'aide d'AppRole et généré un jeton (différent du jeton racine car il est dangereux d'utiliser le même) avec des autorisations de lecture. Cependant, Spring Cloud config pour le moment ne supporte que l'authentification basée sur Token du côté client. Cela signifie que nous générons d'abord un token à partir de Vault, puis le transmettons en tant que variable commandline/env. Quelques points de préoccupation supplémentaires sont l'expiration du jeton (bien que nous puissions avoir un jeton de non-expiration non sûr des avantages/inconvénients), des redémarrages, des problèmes de sécurité, l'instanciation de nouveaux microservices. Il n'y a pas de provision de jetons/authentification dynamiques au niveau de la configuration du cloud.

2. Pour la version intermédiaire, j'ai trouvé que le chiffrement/déchiffrement côté client ne fonctionnait pas à l'heure actuelle en utilisant l'inclusion recommandée de jar RSA. Voici le billet que j'ai ouvert. https://github.com/spring-cloud/spring-cloud-config/issues/805#issuecomment-332491536

Voici quelques-unes de mes observations, s'il vous plaît partagez vos impressions s'il y a une étude de cas/whitepaper cette adresse usecases de voûte de configuration nuage de printemps, la configuration et les défis pour la production environnement micro-services.

Merci

Answer 1

Merci de m'avoir contacté. Je pense que je dirais que le backend du rôle d'application utilise deux jetons distincts, et en effet spring-cloud-config-vault supporte en effet cette fonctionnalité, voir: http://cloud.spring.io/spring-cloud-vault/single/spring-cloud-vault.html#_approle_authentication. Je tire parti du coffre-fort de la même manière que je tire parti du serveur de configuration, conformément à la documentation. Je ne crypte aucune valeur dans ma configuration, je ne les mets pas là. Je mets les valeurs secrètes dans le coffre-fort et le laisse servir la config. Tant que les clés n'entrent pas en collision, vous n'avez rien à faire, sinon vous devrez peut-être ajuster la priorité pour que le coffre-fort gagne, voir à nouveau la documentation que j'ai pointée plus haut. Je ne plaisante pas avec le cryptage/décryptage dans Spring-Cloud-config personnellement. Parce que vous devez vérifier les clés dans SCM ou les distribuer à vos équipes pour le développement local, vous perdez la valeur d'avoir ces clés IMO.

Answer 2

Merci Printemps Cloud vault prend en charge mais pas Spring Spring config avec Vault. Le seul moyen semble être de passer X-Config-token de Microservice à Config Server. Nous sommes un peu sceptiques avec cette partie de la génération de jetons manuellement ou par script. Surtout avec la conteneurisation et quand de nouvelles instances MS vont apparaître.Pas sûr de cette approche en particulier dans la configuration de la production.