Architecture mutualisée
Aperçu
Cette section présente comment réaliser la mutualisation (« multitenancy ») avec des images WorkflowGen et Kubernetes. De par la nature des conteneurs et des outils présents dans Kubernetes, un cluster unique peut avoir plusieurs instances de WorkflowGen avec une isolation relative les unes des autres. La meilleure isolation peut être obtenue avec plusieurs clusters.
À titre de référence pour les meilleures pratiques, consultez les liens suivants vers la documentation de Google Kubernetes Engine et Azure Kubernetes Service :
Problèmes de sécurité
Avant de commencer avec les architectures recommandées, il est important de noter quelques problèmes de sécurité liés à l'utilisation de conteneurs Windows. L'image WorkflowGen est une image de conteneur Windows. Certaines fonctionnalités de sécurité présentes dans les conteneurs Linux ne sont pas nécessairement disponibles dans les conteneurs Windows, comme les profils AppArmor et SELinux et les capacités Linux. Consultez l'article Kubernetes Windows containers in Kubernetes (disponible en anglais uniquement) pour toutes les limitations actuelles.
L'important dans les clusters multi-locataires est d'isoler les locataires les uns des autres et de limiter les actions possibles en cas d'intrusion. Vous pouvez atteindre un bon niveau d'isolement avec les stratégies réseau sur Kubernetes. Ce sont des spécifications qui nécessitent l'installation d'un logiciel tiers pour appliquer ces politiques. Pour le moment, seul le projet Calico a un support Windows (consultez le site Calico for Windows pour plus d'informations).
Pour la sécurité dans le conteneur, à l'heure actuelle, seul runAsUserName est disponible pour exécuter l'instance de conteneur sous un nom d'utilisateur différent de ContainerAdministrator (consultez l'article Kubernetes Configure RunAsUserName for Windows pods and containers pour plus d'informations). Il n'est pas nécessaire pour le conteneur WorkflowGen car les applications Web s'exécutent en tant qu'utilisateur du groupe IIS_IUSRS.
Recommandations
Assurez-vous que le trafic entrant des services Windows WorkflowGen est refusé. Il ne doit pas être ouvert au public.
Assurez-vous que les pods de base de données WorkflowGen ne sont pas accessibles au public. Ils sont uniquement utilisés par le conteneur WorkflowGen.
Les pods des applications Web WorkflowGen ne doivent être accessibles au public que via HTTPS. HTTP est fortement déconseillé. Cependant, vous ne devriez pas du tout pouvoir accéder à WorkflowGen depuis l'intérieur du cluster, même en HTTPS.
Chaque pod WorkflowGen dans un espace de noms ne doit pas pouvoir contacter d'autres pods dans d'autres espaces de noms. Assurez-vous d'avoir une stratégie réseau pour cela.
En général, vous devez toujours refuser tout trafic entrant, sauf si vous en avez explicitement besoin.
Architecture
L'idée de base derrière la mutualisation est d'avoir un déploiement reproductible. Ce schéma montre deux déploiements identiques mais dans des espaces de noms différents. Chacun a ses propres données, configuration et licence. L'isolement entre les espaces de noms doit être appliqué par les stratégies réseau. Vous pouvez éventuellement utiliser un contrôleur Ingress avec cert-manager pour gérer facilement le routage et les certificats.
Cette architecture s'applique également aux environnements multicluster (multirégion). La seule chose qui changera est la façon dont vous acheminez vers l'instance correcte. Les mêmes problèmes de sécurité s'appliquent.
Dernière mise à jour
