Sécurisation du moteur Kubernetes

Charges de travail mutuellement fiables

Pour le moment, il n'est pas recommandé d'exécuter des charges de travail qui ne sont pas approuvées mutuellement dans la même grappe. Par exemple, vous ne devez pas exécuter les charges de travail suivantes dans la même grappe :

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

Charges de travail avec différents niveaux de confiance

Envisagez d'avoir des grappes distinctes si vous avez plusieurs locataires, équipes ou utilisateurs qui accèdent à la même grappe avec des niveaux d'approbation différents. Comme mentionné dans les sections suivantes, Kubernetes et OKE offrent des méthodes pour isoler les charges de travail. Toutefois, ces méthodes ne sont actuellement pas suffisantes pour une architecture multilocation regroupant plusieurs entreprises.

Les kubelets ont un accès en lecture aux ressources

Un kubelet exécuté sur un noeud de travail d'une grappe créée par OKE ne peut pas modifier des ressources qui n'appartiennent pas au noeud du kubelet. Pour plus d'informations, voir les détails sur le contrôleur d'admission NodeRestriction dans la documentation sur Kubernetes.

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

• services
• points d'extrémité
• noeuds
• pods
• clés secrètes, mappages de configuration et volumes persistants liés au noeud du kubelet

Pour plus d'informations, voir Utilisation de l'autorisation de noeud dans la documentation sur Kubernetes.

Compartiments du groupe de noeuds

Les groupes de noeuds d'une grappe peuvent couvrir des compartiments. Toutefois, si l'utilisation de plusieurs compartiments offre un moyen pratique de regrouper et de gérer des noeuds de travail, elle ne fournit aucun isolement entre les noeuds de travail dans la grappe. Toute charge de travail peut être programmée pour n'importe quel groupe de noeuds, quel que soit le compartiment. Un cas d'utilisation valide pour l'utilisation de plusieurs compartiments pour un groupe de noeuds consiste à créer facilement des groupes dynamiques et des politiques IAM pour les noeuds de travail. Cas d'utilisation non valide : Placer chaque groupe de noeuds exécutant une charge de travail de client dans un compartiment distinct, en partant de l'hypothèse que les compartiments fournissent un certain niveau de sécurité ou d'isolement.

Sous-réseaux du groupe de noeuds

Nous recommandons d'utiliser uniquement des sous-réseaux privés pour les groupes de noeuds. Une passerelle de service doit être configurée pour fournir l'accès aux services Oracle Cloud Infrastructure. A service gateway cannot be used if the subnets are public with an internet gateway . Si vos sous-réseaux privés ont besoin d'accéder à Internet, utilisez une passerelle NAT .

Contrôler les noeuds auxquels les pods peuvent accéder

Par défaut, un pod peut être programmé sur n'importe quel noeud de la grappe. Kubernetes met à la disposition des utilisateurs finaux un large jeu de politiques pour contrôler le placement des pods dans des noeuds ainsi que le placement et l'éviction des pods en fonction de marques. Pour de nombreuses grappes, l'utilisation de ces politiques pour séparer les charges de travail peut être une convention que les auteurs adoptent ou appliquent au moyen d'outils. Ces contrôles de placement ne sont pas appropriés dans un environnement multilocataire où les utilisateurs disposant de fonctionnalités de déploiement ne sont pas des utilisateurs de confiance. Si vous avez des utilisateurs non approuvés qui déploient du code,envisagez d'utiliser une grappe par groupe non approuvé.

Limiter l'accès accordé aux principaux d'instance

Par défaut, tous les pods figurant sur un noeud peuvent accéder aux certificats du principal d'instance à l'aide du point d'extrémité des métadonnées d'instance. Pour éviter l'escalade de privilèges au moyen de principaux d'instance, vous devez isoler les charges de travail des groupes de noeuds avec des groupes dynamiques différents afin que les pods d'un groupe de noeuds donné disposent seulement du jeu minimal de privilèges requis pour fonctionner.

Par exemple, supposons que vous ayez les deux charges de travail suivantes, qui nécessitent un accès différent :

• LogArchiver - Requiert l'accès pour la gestion des seaux et des objets dans le service de stockage d'objets.
• HostMonitor - Nécessite l'accès à l'API du service de calcul pour gérer les instances

L'approche la plus simple consiste à les programmer dans le même groupe de noeuds et à fournir au principal d'instance tous les accès requis. Toutefois, cette approche accroît l'incidence potentielle si l'une des charges de travail est compromise. Une meilleure approche consisterait à programmer les charges de travail dans des groupes de noeuds séparés, avec le jeu de droits d'accès limité requis par les principaux d'instance pour la charge de travail concernée.

Accès du conteneur par blocs aux métadonnées d'instance

Le meilleur moyen de bloquer l'accès consiste à utiliser un plugiciel de politique de réseau comportant une politique par défaut de type "Tout refuser". Ensuite, vous pouvez accorder l'accès aux pods et aux réseaux, de manière explicite, à l'aide de ressources NetworkPolicy dans Kubernetes au moyen des sélecteurs d'étiquette. Si aucun plugiciel de politique de réseau n'est installé, vous pouvez utiliser une règle IPTables pour limiter l'accès de tous les pods sur l'hôte. Il est recommandé de ne pas utiliser cette approche pour bloquer un sous-jeu de pods sur un hôte.

Important : Le type de ressource NetworkPolicys et la règle IPTables suivante s'appliquent uniquement aux conteneurs situés dans le réseau superposé au pod. Les conteneurs et services s'exécutant dans le réseau hôte ne sont pas touchés par l'une ou l'autre des options suivantes :

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

Politiques de réseau

Les politiques de réseau dans Kubernetes permettent aux administrateurs de définir la façon dont les groupes de pods peuvent communiquer avec d'autres pods dans la grappe. En outre, les politiques de réseau permettent de définir la façon dont les groupes de pods peuvent communiquer avec les services en dehors de la grappe (par exemple, services Oracle Cloud Infrastructure).

Pour restreindre l'accès à l'aide de politiques de réseau, vous devez installer un plugiciel de réseau. Les plugiciels de réseau configurent et appliquent les politiques de réseau définies dans Kubernetes. De nombreuses options de plugiciel réseau sont disponibles. Vous pouvez suivre les instructions fournies ici pour installer et configurer Calico dans votre grappe. Les plugiciels de politique de réseau fonctionnent en limitant l'accès à l'hôte. Pour plus d'informations sur l'installation de Calico dans OKE, voir Exemple : Installation de Calico et configuration de politiques de réseau.

Listes de sécurité du groupe de noeuds

Les administrateurs de réseau peuvent définir des règles de liste de sécurité sur les sous-réseaux du groupe de noeuds pour restreindre l'accès depuis et vers les noeuds de travail. La définition de règles de liste de sécurité permet aux administrateurs d'appliquer des restrictions de réseau qui ne peuvent pas être remplacées sur les hôtes dans votre grappe.

Comme la communication de pod à pod a lieu dans un réseau superposé VXLAN sur les noeuds de travail, vous ne pouvez pas utiliser des règles de liste de sécurité pour la restreindre. Toutefois, vous pouvez utiliser des listes de sécurité pour limiter l'accès depuis et vers vos noeuds de travail.

Important : Un jeu minimal de règles de liste de sécurité doit exister sur les sous-réseaux du groupe de noeuds pour garantir que la grappe peut fonctionner. Voir Exemples de configurations de ressources de réseau pour plus d'informations sur le jeu minimal de règles de liste de sécurité à définir avant de modifier vos règles de liste de sécurité.

Utiliser des condensés d'image au lieu de marqueurs

Nous vous recommandons d'extraire uniquement des images à l'aide de condensés d'image et non à l'aide de marqueurs (car les marqueurs d'image sont mutables). Un condensé d'image est un condensé sha256 de votre image, qui permet à Docker de vérifier si l'image qu'il a téléchargée correspond à vos attentes.

Exemple d'ID condensé d'image :

sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182

Extrayez l'image comme illustré 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

Limiter l'utilisation des ressources

Le quota de ressource limite le nombre ou la capacité des ressources octroyées à un espace de noms. Les quotas sont généralement utilisés pour limiter la quantité d'UC, de mémoire ou de disque persistant qu'un espace de noms peut affecter. Ils permettent également de contrôler le nombre de pods, de services ou de volumes dans chaque espace de noms.

Les intervalles de limite restreignent la taille maximale ou minimale de certaines des ressources ci-dessus, afin d'empêcher les utilisateurs d'indiquer des valeurs trop élevées ou trop faibles lorsqu'ils demandent des ressources communément réservées (mémoire par exemple) ou pour fournir des limites par défaut lorsqu'aucune limite n'est spécifiée.

L'accès aux quotas de ressource peut être restreint au moyen de politiques RBAC dans Kubernetes. Un administrateur peut ainsi s'assurer que les utilisateurs d'une grappe ne peuvent pas utiliser des ressources auxquelles ils n'ont pas le droit d'accéder. Pour plus d'informations, voir Limitation de l'utilisation des ressources dans une grappe dans la documentation Kubernetes.