Sécurisation de Container Engine for Kubernetes

Charges de travail mutuellement non sécurisées

A ce stade, il n'est pas recommandé d'exécuter des charges globales qui ne se font pas confiance mutuellement dans le même cluster. Par exemple, vous ne devez pas exécuter les charges globales suivantes dans le même cluster :

• Charges globales de développement et de production
• Plan de contrôle et plan de données
• Charges globales exécutant un code client arbitraire

Charges de travail avec différents niveaux de confiance

Envisagez d'avoir des clusters distincts si vous avez plusieurs locataires, équipes ou utilisateurs qui accèdent au même cluster avec des niveaux de confiance différents. Comme mentionné dans les sections ci-après, Kubernetes et OKE proposent des méthodes pour isoler les charges globales. Cependant, ces méthodes ne sont actuellement pas suffisantes pour une architecture colocative publique.

Les Kubelets ont accès en lecture aux ressources

Un kubelet exécuté sur un noeud de processus actif dans un cluster créé par OKE ne peut pas modifier les ressources qui n'appartiennent pas au noeud du kubelet. Pour plus d'informations, reportez-vous aux détails du contrôleur d'admission NodeRestriction dans la documentation Kubernetes.

Notez, en particulier lors de l'exécution de charges globales colocatives, que même si un kubelet ne peut pas modifier des ressources qui n'appartiennent pas à son noeud, le kubelet peut toujours lire ces ressources. Ces ressources peuvent inclure :

• services
• adresses
• noeuds
• pods
• clés secrètes, mappages de configuration et volumes persistants liés au noeud du kubelet

Pour plus d'informations, reportez-vous à Utilisation de l'autorisation de noeud dans la documentation Kubernetes.

Compartiments de pool de noeuds

Les pools de noeuds d'un cluster peuvent s'étendre sur plusieurs compartiments. Cependant, bien que l'utilisation de plusieurs compartiments permet de regrouper et de gérer facilement les noeuds de processus actifs, elle n'offre aucune isolation entre ces noeuds dans le cluster. Une charge globale peut être programmée dans n'importe quel pool de noeuds, quel que soit le compartiment. L'un des cas d'emploi valides permettant d'utiliser plusieurs compartiments pour un pool de noeuds consiste à créer facilement des groupes dynamiques et des stratégies IAM pour les noeuds de processus actifs. En revanche, le placement de chaque pool de noeuds exécutant une charge globale client dans un compartiment distinct en supposant que les compartiments fournissent un certain type de limite ou d'isolation de sécurité n'est pas un cas d'emploi valide pour les compartiments multiples.

Sous-réseaux de pool de noeuds

Nous vous recommandons d'utiliser uniquement des sous-réseaux privés pour les pools de noeuds. Une passerelle de service doit être configurée de manière à fournir l'accès aux services Oracle Cloud Infrastructure. Vous ne pouvez pas utiliser une passerelle de service si les sous-réseaux sont publics avec une passerelle Internet . Si vos sous-réseaux privés requièrent un accès à Internet, utilisez une passerelle NAT .

Contrôle des noeuds auxquels les pods peuvent accéder

Par défaut, un pod peut être programmé sur n'importe quel noeud du cluster. Kubernetes offre un vaste ensemble de stratégies permettant de contrôler le placement des pods sur les noeuds, ainsi que le placement et l'expulsion des pods sur la base du marquage des données pour suivi, disponibles pour les utilisateurs finals. Pour de nombreux clusters, l'utilisation de ces stratégies pour séparer les charges globales peut être une convention que les auteurs adoptent ou mettent en application via les outils. Ces contrôles de placement ne conviennent pas dans un environnement colocatif où les utilisateurs dotés de capacités de déploiement ne sont pas sécurisés. Si des utilisateurs non sécurisés déploient du code, vous devez envisager de disposer d'un cluster par groupe non sécurisé.

Limitation de l'accès accordé aux principaux d'instance

Par défaut, tous les pods d'un noeud peuvent accéder aux certificats de principal d'instance à l'aide de l'adresse de métadonnées d'instance. Afin d'éviter l'escalade des privilèges via les principaux d'instance, vous devez isoler les charges globales sur les pools de noeuds avec des groupes dynamiques différents de sorte que les pods d'un pool de noeuds donné disposent de l'ensemble minimal de privilèges requis pour fonctionner.

Supposons, par exemple, que vous avez les deux charges globales suivantes, qui nécessitent des accès différents :

• LogArchiver : requiert un accès permettant de gérer les buckets et les objets dans Object Storage
• HostMonitor : requiert un accès à l'API Compute pour gérer les instances

L'approche la plus simple consiste à les programmer dans le même pool de noeuds et à fournir au principal d'instance tous les accès requis. Cependant, si l'une des charges globales est compromise, l'impact en est plus fort. La meilleure approche consiste à programmer les charges globales sur des pools de noeuds distincts, avec l'ensemble limité d'accès dont les principaux d'instance ont besoin pour la charge globale concernée.

Blocage de l'accès de conteneur aux métadonnées d'instance

La méthode de prédilection pour bloquer l'accès est d'utiliser un module d'extension de stratégie réseau dont la stratégie par défaut consiste à tout refuser. Ensuite, octroyez explicitement l'accès aux pods et aux réseaux à l'aide des ressources NetworkPolicy dans Kubernetes via les sélecteurs de libellé. Si aucun module d'extension de stratégie réseau n'est installé, vous pouvez utiliser une règle IPTables pour restreindre l'accès à partir de tous les pods sur l'hôte. Nous vous recommandons de ne pas adopter cette approche pour bloquer un sous-ensemble de pods sur un hôte.

Important : NetworkPolicys et la règle IPTable suivante s'appliquent uniquement aux conteneurs sur le réseau superposé du pod. Les conteneurs et les services exécutés sur le réseau de l'hôte ne sont concernés par aucune des deux options :

iptables --insert FORWARD 1 --in-interface veth+ --destination 169.254.0.0/16 --jump DROP

Stratégies réseau

Les stratégies réseau dans Kubernetes permettent aux administrateurs de définir la façon dont les groupes de pods peuvent communiquer avec les autres pods du cluster. De même, les stratégies réseau vous permettent de définir la façon dont les groupes de pods peuvent communiquer avec les services situés hors du cluster (services Oracle Cloud Infrastructure par exemple).

Pour restreindre l'accès à l'aide de stratégies réseau, vous devez installer un module d'extension réseau. Les modules d'extension réseau configurent et mettent en application les stratégies réseau définies dans Kubernetes. De nombreuses options de modules d'extension réseau sont disponibles. Vous pouvez suivre les instructions fournies ici pour installer et configurer Calico dans votre cluster. Les modules d'extension de stratégie réseau fonctionnent en restreignant l'accès sur l'hôte. Pour plus d'informations sur l'installation de Calico dans OKE, reportez-vous à Exemple : installation de Calico et configuration de stratégies réseau.

Listes de sécurité de pool de noeuds

Les administrateurs réseau peuvent définir des règles de liste de sécurité sur les sous-réseaux de pool de noeuds pour limiter l'accès aux noeuds de processus actifs ainsi que l'accès à partir de ces derniers. La définition de règles de liste de sécurité permet aux administrateurs d'appliquer des restrictions réseau qui ne peuvent pas être remplacées sur les hôtes de votre cluster.

Toutes les communications pod-à-pod se produisant dans un réseau superposé VXLAN sur les noeuds de processus actifs, vous ne pouvez pas utiliser des règles de liste de sécurité pour limiter les communications pod-à-pod. Toutefois, vous pouvez utiliser des listes de sécurité pour limiter l'accès à vos noeuds de processus actifs ainsi que l'accès à partir de ceux-ci.

Important : un ensemble minimal de règles de liste de sécurité doit exister sur les sous-réseaux de pool de noeuds pour assurer le fonctionnement du cluster. Reportez-vous à Exemples de configuration de ressource réseau pour plus d'informations sur l'ensemble minimal de règles de liste de sécurité avant de modifier les règles de liste de sécurité.

Utilisation de condensés d'image à la place des balises

Nous vous recommandons d'extraire les images uniquement à l'aide des condensés d'image, et non à l'aide de balises (car les balises d'image sont mutables). Un condensé d'image est le condensé sha256 de votre image, ce qui permet à la commande docker de vérifier que l'image téléchargée est celle attendue.

Exemple d'ID de condensé d'image :

sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182

Extrayez l'image comme indiqué dans l'exemple suivant :

docker pull acme@sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182

Vous pouvez utiliser la commande suivante pour afficher tous les condensés de vos images locales :

docker images --digests

Limitation de l'utilisation des ressources

Le quota de ressource limite le nombre ou la capacité de ressources accordé à un espace de noms. Il est principalement utilisé pour limiter la part d'UC, de mémoire ou de disque persistant qu'un espace de noms peut allouer, mais il peut également contrôler le nombre de pods, de services ou de volumes présents dans chaque espace de noms.

Les plages de limites précisent la taille maximale ou minimale de certaines ressources ci-dessus, afin d'éviter aux utilisateurs de demander des valeurs anormalement élevées ou faibles pour des ressources fréquemment réservées comme la mémoire, ou de fournir des limites par défaut lorsqu'aucune n'est indiquée.

L'accès aux quotas de ressources peut être limité à l'aide de stratégies RBAC dans Kubernetes. Cela permet à un administrateur de s'assurer que les utilisateurs d'un cluster ne peuvent pas utiliser les ressources auxquelles ils ne doivent pas avoir accès. Pour plus d'informations, reportez-vous à Limitation de l'utilisation des ressources dans un cluster dans la documentation Kubernetes.