Sécurité Kubernetes & Zero Trust
En tant que programme cloud-native, Kubernetes fait face à de nombreux défis en matière de sécurité qui, pour beaucoup, sont liés à la nature dispersée de l’architecture cloud. Différents workloads peuvent être exécutés sur plusieurs sites distincts, y compris sur plusieurs clouds, ainsi que sur des serveurs sur site et hors site. Le « champ des menaces », qui regroupe l’ensemble des emplacements où une attaque ou une erreur peut se produire, s’en trouve donc considérablement élargi, mais cela peut également avoir un impact sur la visibilité et complexifier le monitoring des conteneurs et la détection des problèmes.

Si la solution Kubernetes est intrinsèquement sécurisée – et ne répond qu’aux requêtes qu’elle est capable d’authentifier et qui ont été autorisées au préalable –, elle offre également des options de configuration sur mesure aux développeurs, ce qui signifie que la qualité de sa posture de sécurité ne dépend que des politiques de contrôle d’accès basé sur les rôles (RBAC) configurées par ces mêmes développeurs. Kubernetes utilise également ce que l’on appelle un « réseau plat » ou « flat network » qui permet à des ensembles de conteneurs (également appelés pods) de communiquer par défaut avec d’autres conteneurs. Cela pose des problèmes de sécurité, car en théorie, les attaquants qui parviennent à compromettre un pod peuvent accéder à d’autres ressources au sein du même cluster.

En dépit de cette complexité, la solution la plus susceptible d’atténuer ce risque est celle de la stratégie Zero Trust. En raison de l’importance de la surface d’attaque, lorsqu’il s’agit de bâtir une architecture à l’aide de Kubernetes, il est essentiel de pouvoir s’appuyer sur une conception de réseau plutôt ouverte, avec des workloads répartis sur différents environnements et une architecture Zero Trust, qui repose sur le principe fondamental de ne jamais faire confiance et de toujours effectuer des vérifications avant d’entreprendre une action.

En se fondant sur ce principe de méfiance permanente, une architecture Zero Trust permet de ne pas concentrer la sécurité au sein du périmètre d’une application, tout en maintenant des procédures de sécurité strictes pour chaque utilisateur, appareil ou connexion. Dans le contexte de l’architecture fluide et décentralisée de Kubernetes, ce type de stratégie est indispensable.

Sauvegarde et reprise d’activité après sinistre
Un autre principe de base essentiel, lorsqu’il s’agit de minimiser les risques liés aux applications Kubernetes, réside dans la sauvegarde et la reprise d’activité après sinistre. Même si ce concept est assez commun, il y a tout de même de nombreuses considérations spécifiques à prendre en compte lors d’une sauvegarde Kubernetes ou de conteneurs. Ces exigences particulières en matière de sauvegarde des données s’expliquent par le fait que l’architecture Kubernetes est fondamentalement différente des autres : par exemple, elle ne dispose pas d’une cartographie applicative vers des serveurs ou des machines virtuelles.

Les systèmes de sauvegarde de Kubernetes doivent également être centrés sur les applications plutôt que sur l’infrastructure en raison de la philosophie DevOps et des principes de « shift left », grâce auxquels les développeurs sont davantage en mesure de contrôler l’infrastructure et les déploiements. D’autres caractéristiques spécifiques à la sauvegarde Kubernetes sont liées à l’échelle des applications, aux lacunes en matière de protection des données et à l’intégration de l’écosystème.

Dans la perspective d’une restauration d’environnement Kubernetes, il est nécessaire de mettre au point un plan d’exécution détaillé qui soit en mesure d’identifier les dépendances d’un cluster et de mettre à jour les applications pour refléter les nouveaux composants de stockage et de traduire ce plan en interfaces de programmation d’applications (API) Kubernetes pertinentes. Alors que la sauvegarde nécessite une solution Kubernetes native plus personnalisée, de tels processus de restauration demeurent essentiels pour garantir la bonne santé de l’entreprise sur le long terme. Sachant qu’une interruption d’activité coûte environ 1 459 € par minute, il va sans dire que des capacités de restauration et de reprise d’activité après sinistre efficaces constituent des atouts indispensables dans le contexte actuel.

En outre, la sauvegarde représente une immense valeur ajoutée dans le cadre du testing, du développement et de la mobilité des applications. La mobilité applicative fait référence à la capacité de migrer une application vers un environnement différent – au sein d’installations sur site, de clouds, de clusters ou de distributions Kubernetes. Il s’agit d’un aspect de plus en plus essentiel, alors que les environnements informatiques gagnent en complexité et que les entreprises doivent répondre à de nouvelles exigences métier, adopter de nouvelles plateformes technologiques et optimiser leurs dépenses.