Sécurité - Recommandations

Meilleure pratique : Planifier le niveau d'exposition

Nous vous recommandons de répondre aux questions suivantes avant d'implémenter un plan de sécurité pour les clusters que vous créez à l'aide de Kubernetes Engine :

• Quelle exposition Internet souhaitez-vous que les clusters aient ?
• Comment envisagez-vous d'exposer les charges de travail en interne à votre VCN et/ou en externe à Internet ?
• Comment prévoyez-vous de faire évoluer les charges de travail ?
• Quels types de services Oracle le cluster utilisera-t-il ?

Après avoir répondu aux questions précédentes, nous vous recommandons d'examiner les meilleures pratiques suivantes :

• Meilleure pratique : Créer des clusters privés

  Nous vous recommandons de créer des clusters natifs VCN avec l'adresse d'API Kubernetes dans un sous-réseau privé si vous souhaitez uniquement exposer les charges de travail en interne à votre VCN et non à Internet. Ces clusters sont parfois appelés clusters privés.

  Lorsque vous configurez des clusters privés, tous les composants du plan de contrôle (y compris l'adresse d'API Kubernetes du cluster) se trouvent dans un espace réseau RFC 1918 privé. Par conséquent, l'accès est limité et l'ensemble du trafic est conservé sur les réseaux d'Oracle. Vous pouvez verrouiller l'accès à l'API Kubernetes sur un VCN spécifique.

  Si vous n'utilisez pas de clusters privés, l'adresse d'API Kubernetes du cluster dispose d'une adresse IPv4 publique et tout le trafic vers l'API (y compris le trafic provenant des pools de noeuds du cluster) passe sur l'espace de réseau public.

  Reportez-vous à Annonce des clusters Kubernetes privés.

• Meilleure pratique : Placer toutes les applications dans des sous-réseaux privés

  Nous vous recommandons de placer les instances de calcul de noeud de processus actif exécutant des charges de travail d'application dans des sous-réseaux privés afin de réduire l'exposition d'un service à Internet et de configurer des équilibreurs de charge pour y accéder.

  L'isolement des instances de service d'Internet réduit la surface d'attaque d'un service. La plupart des instances de service n'ont pas besoin d'être directement exposées à Internet.

  Reportez-vous à Configuration de ressources réseau pour la création et le déploiement de clusters.

• Meilleure pratique : Limiter le trafic du cluster à l'aide de groupes de sécurité réseau

  Nous vous recommandons de définir des règles de sécurité dans les groupes de sécurité réseau (plutôt que dans les listes de sécurité) pour le VCN dans lequel vous souhaitez créer et déployer des clusters.

  Kubernetes Engine crée les règles de sécurité requises par défaut, mais vous pouvez les modifier pour répondre à vos exigences spécifiques.

  Reportez-vous à Configuration de règles de sécurité dans des groupes de sécurité réseau et/ou des listes de sécurité.

Meilleure pratique : Appliquer régulièrement des patches de sécurité

Nous vous recommandons de mettre régulièrement à jour le système d'exploitation exécuté sur les noeuds de processus actif afin d'appliquer les derniers patches de sécurité.

Les noeuds de processus actif dans les clusters créés par Kubernetes Engine exécutent une image Linux renforcée.

Il est important de maintenir le système d'exploitation du noeud de processus actif durci et sécurisé car les services exécutés sur les noeuds de processus actif incluent l'exécution de conteneur, le kubelet et le kube-proxy.

Une autre bonne pratique consiste à utiliser le test de référence Kubernetes CIS (Center for Internet Security) pour les noeuds de processus actif.

Reportez-vous à Création de noeuds de salarié avec des propriétés mises à jour.

Meilleure pratique : utiliser une combinaison de stratégies réseau Kubernetes et de groupes de sécurité réseau

Nous vous recommandons d'envisager d'implémenter des stratégies réseau Kubernetes en combinaison avec des groupes de sécurité réseau OCI (recommandé) et/ou des listes de sécurité.

Une combinaison de stratégies réseau Kubernetes (pour sécuriser les communications réseau au niveau du pod) et de groupes de sécurité réseau et/ou de listes de sécurité OCI (pour sécuriser les communications réseau au niveau de l'hôte) peut offrir la meilleure posture de sécurité réseau.

Reportez-vous à Sécurité réseau.

Meilleure pratique : utiliser des groupes de sécurité réseau avec des outils d'infrastructure en tant que code (tels que Terraform)

Nous recommandons d'utiliser des règles de sécurité dans les groupes de sécurité réseau plutôt que dans les listes de sécurité, lors de l'implémentation d'un contrôleur d'équilibrage de charge conjointement avec des outils d'infrastructure en tant que code tels que Terraform,

Pour utiliser Kubernetes à grande échelle, vous utilisez généralement des outils de type Infrastructure-as-Code tels que Terraform pour suivre l'état des ressources d'infrastructure. Par exemple, pour maintenir l'infrastructure dans son état d'origine et celui prévu, vous exécutez et réexécutez généralement une configuration Terraform. Toutefois, un conflit potentiel survient pour les services Kubernetes de type LoadBalancer si cloud-controller-manager ajoute ou met à jour des règles de sécurité dans la liste de sécurité utilisée par un sous-réseau. Les modifications apportées aux règles de sécurité dans une liste de sécurité ne sont pas répercutées dans la configuration Terraform. Par conséquent, lors de la prochaine exécution de Terraform, les modifications apportées aux règles de sécurité dans la liste de sécurité sont marquées comme une dérive par rapport à l'état d'origine et sont ignorées lorsque vous appliquez la configuration Terraform. Sans les règles de sécurité, les applications déployées sur un cluster peuvent échouer car l'équilibreur de charge ou l'équilibreur de charge réseau provisionnant le service de type LoadBalancer ne peut pas traiter le trafic ni communiquer avec les noeuds hébergeant les pods d'application.

Vous pouvez configurer cloud-controller-manager pour ne pas gérer les règles de sécurité dans la liste de sécurité d'un sous-réseau, ou pour ne gérer que les règles de sécurité sortantes pour l'équilibreur de charge ou l'équilibreur de charge réseau. Toutefois, dans les deux cas, vous devez configurer manuellement les ports sélectionnés chaque fois qu'un nouveau service est déployé sur le cluster ou ouvrir complètement la plage de ports du noeud. Aucune des deux solutions n'est idéale, car l'une implique un travail manuel lors de l'exécution et l'autre présente une vulnérabilité potentielle en matière de sécurité.

Pour éviter que cloud-controller-manager ne mute une ressource de liste de sécurité en ajoutant ou en mettant à jour des règles de sécurité, et que ces modifications soient ensuite ignorées lorsque vous appliquez une configuration Terraform, nous recommandons donc au cloud-controller-manager d'utiliser des groupes de sécurité réseau. Les règles de sécurité définies pour un groupe de sécurité réseau sont des ressources à part entière dotées de leurs propres OCID et indépendantes du groupe de sécurité réseau lui-même. Etant donné que la modification des règles de sécurité de groupe de sécurité réseau ne modifie pas la ressource de groupe de sécurité réseau elle-même, aucune modification n'est ignorée lorsque vous appliquez une configuration Terraform.

Pour plus d'informations, reportez-vous à Utilisation de l'annotation oci.oraclecloud.com/security-rule-management-mode pour gérer les règles de sécurité dans les groupes de sécurité réseau et les listes de sécurité.

Meilleure pratique : Rotation régulière des secrets et des certificats

Nous vous recommandons de définir des durées de vie courtes pour les clés secrètes, les informations d'identification et les certificats, et d'automatiser leur rotation.

Meilleure pratique : Exécuter toutes les applications en tant qu'utilisateur non privilégié

Nous vous recommandons d'exécuter toutes les applications en tant qu'utilisateur sans privilège. C'est également une exigence dans un certain nombre de normes réglementaires.

L'exécution d'applications en tant qu'utilisateur non privilégié garantit que si un attaquant exploite une vulnérabilité (telle qu'une vulnérabilité d'exécution de code à distance), il est limité à l'accès limité accordé à l'utilisateur non privilégié. L'attaquant aura également plus de difficulté à escalader une attaque pour obtenir des privilèges supplémentaires, pour sortir d'un conteneur ou pour obtenir un accès root via un bogue du noyau.

Meilleure pratique : traiter les conteneurs comme immuables

Nous vous recommandons de définir les systèmes de fichiers racine de conteneur en lecture seule. Si vous autorisez la mise à jour des bibliothèques et des fichiers binaires du système de fichiers racine d'un conteneur, vous rendez l'ensemble du cluster vulnérable aux attaques.

La nature éphémère des conteneurs offre d'importants avantages en matière de sécurité. Au fur et à mesure que les applications et leur environnement immédiat sont déployés et mis à niveau dans leur ensemble, les attaques persistantes sur l'ensemble du système sont plus difficiles. La prévention de la modification du système de fichiers racine renforce la sécurité, à la fois en réduisant la probabilité de menaces et en réduisant leur impact potentiel.

Meilleure pratique : Envisagez de décharger le traitement SSL vers des contrôleurs ou des équilibreurs de charge entrants (si autorisé)

Nous vous recommandons de décharger le traitement SSL vers les contrôleurs ou les équilibreurs de charge entrants si la stratégie de sécurité réseau de votre organisation vous donne la flexibilité nécessaire.

Les contrôleurs d'entrée (par exemple, Traefik, NGINX Open Source) vous permettent d'acheminer intelligemment le trafic HTTP/S provenant de l'extérieur du cluster vers des services exécutés dans le cluster. Le service Oracle Cloud Infrastructure Load Balancer prend en charge les protocoles de cryptage de transport (SSL et TLS) permettant de crypter les données en transit.

Le trafic crypté peut être arrêté à différents endroits du réseau (par exemple, au niveau de l'équilibreur de charge, de la ressource entrante, du pod). Le mode et l'emplacement de terminaison des connexions SSL dépendent en fin de compte de la stratégie de sécurité réseau de votre organisation. Par exemple, si la stratégie de sécurité réseau de votre organisation requiert un cryptage de bout en bout, le trafic doit être décrypté au niveau du pod. Le décryptage du trafic entraînera une charge supplémentaire sur le pod, car il devra passer des cycles à établir l'établissement de la liaison initiale et le traitement SSL/TLS consomme beaucoup de CPU. Par conséquent, si la stratégie de sécurité réseau de votre organisation vous donne la flexibilité nécessaire, déchargez le traitement SSL sur le contrôleur d'entrée ou l'équilibreur de charge.

Meilleures pratiques pour l'audit, la journalisation et la surveillance

Nous vous recommandons d'appliquer les meilleures pratiques suivantes lorsque vous activez l'audit, la journalisation et la surveillance :

• Meilleure pratique : consulter régulièrement les journaux

  Nous vous recommandons de vérifier régulièrement les journaux d'audit du serveur d'API Kubernetes et les journaux d'application des applications exécutées sur les noeuds de processus actif du cluster. La vérification régulière des journaux vous permet d'identifier les menaces ou les vulnérabilités dans le cluster.

  Reportez-vous à Observation des clusters Kubernetes.

• Meilleure pratique : Activer la journalisation d'audit

  Nous vous recommandons d'activer la journalisation d'audit et d'enregistrer les journaux d'audit dans un référentiel sécurisé pour une analyse ultérieure en cas de compromission.

  Reportez-vous à Visualisation des journaux d'audit du serveur d'API Kubernetes.

• Meilleure pratique : Utiliser la journalisation basée sur un cluster Kubernetes

  Nous vous recommandons d'utiliser la journalisation basée sur un cluster Kubernetes pour enregistrer l'activité du conteneur dans un sous-système de journalisation central. La sortie standard et la sortie d'erreur standard de chaque conteneur d'un cluster Kubernetes peuvent être incluses (à l'aide d'un agent tel que Fluentd exécuté sur chaque noeud) dans des outils tels que Elasticsearch, et affichées avec Kibana.

  Reportez-vous à Architecture de journalisation dans la documentation Kubernetes.

• Meilleure pratique : Surveiller les composants d'un cluster

  Nous vous recommandons de surveiller les conteneurs, pods, applications, services et autres composants de cluster à l'aide d'outils tels que Prometheus, Grafana et Jaeger.

• Meilleure pratique : consigner les métadonnées de trafic réseau et les analyser régulièrement

  Nous vous recommandons d'activer les journaux de flux VCN dans le service Oracle Cloud Infrastructure Logging pour capturer les métadonnées sur le trafic passant par un VCN, telles que l'adresse IP et le port source et de destination, ainsi que les paquets acceptés/supprimés. Après l'avoir capturée, analysez régulièrement les métadonnées pour identifier les activités suspectes ou inhabituelles entre les ressources du VCN, y compris entre les pods. Reportez-vous à Surveillance du trafic réseau à l'aide des journaux de flux Oracle VCN.

Reportez-vous à Observation des clusters Kubernetes.

Meilleure pratique : utiliser des images de conteneur petites et sécurisées

Nous vous recommandons de créer des images de conteneur petites et sécurisées qui contiennent uniquement les packages, bibliothèques et outils requis par l'application du conteneur.

Un nouveau développeur commet souvent l'erreur d'utiliser l'image de base, même s'il n'a pas besoin de la majorité des packages et des bibliothèques dans l'image de base. Nous vous recommandons de choisir des images plus petites qui nécessitent moins d'espace de stockage. Une image plus petite vous aide à extraire et à construire l'image plus rapidement. Et avec une image plus petite, il y a moins de risques de problèmes de sécurité.

Pour réduire davantage la taille de l'image du conteneur, nous vous recommandons d'installer uniquement les outils nécessaires à l'application du conteneur. N'incluez pas d'outils de débogage dans les conteneurs de production.

Si les applications n'ont besoin que d'outils réseau au démarrage du pod, au lieu de mettre des outils exploitables tels que curl dans une image pour les applications à longue durée d'exécution, nous vous recommandons d'envisager d'utiliser des conteneurs init distincts ou de fournir les données à l'aide d'une méthode plus native de Kubernetes (telle que ConfigMaps).

Nous vous recommandons également de tenir les images de conteneur à jour et de rechercher les nouvelles versions de l'image de base et des outils tiers que vous installez.

Meilleures pratiques : limiter l'exposition aux titres de compétences

Nous vous recommandons de ne pas définir d'informations d'identification dans le code d'application. Utilisez plutôt un coffre numérique (tel qu'Oracle Cloud Infrastructure Vault) pour stocker et extraire des clés et des informations d'identification numériques.

Meilleure pratique : utiliser un jeton d'authentification approprié pour accéder au cluster

Nous vous recommandons d'utiliser uniquement le jeton d'authentification généré par la commande dans le fichier kubeconfig d'un cluster lorsque vous accédez au cluster avec kubectl et le tableau de bord Kubernetes. Lorsque d'autres processus et outils accèdent au cluster, utilisez un jeton d'authentification non spécifique à l'utilisateur pour l'authentification.

Lorsque vous configurez le fichier kubeconfig pour un cluster, le fichier contient par défaut une commande de l'interface de ligne de commande Oracle Cloud Infrastructure pour générer un jeton d'authentification spécifique à l'utilisateur de courte durée, de portée cluster. Le jeton d'authentification généré par la commande d'interface de ligne de commande permet d'authentifier les utilisateurs individuels ayant accès au cluster à l'aide de kubectl et du tableau de bord Kubernetes.

Toutefois, le jeton d'authentification généré ne permet pas d'authentifier les processus et les outils qui accèdent au cluster, tels que les outils d'intégration continue et de déploiement continu. Pour garantir leur accès au cluster, ces outils requièrent des jetons d'authentification à long terme qui ne sont pas propres à l'utilisateur. L'une des solutions est d'utiliser un compte de service Kubernetes.

Reportez-vous à Ajout d'un jeton d'authentification de compte de service à un fichier Kubeconfig.

Meilleure pratique : configurer l'accès avec le moins de privilèges lors de la création de RoleBindings et ClusterRoleBindings

Nous vous recommandons de définir uniquement Kubernetes RoleBindings et ClusterRoleBindings qui incluent l'ensemble de droits d'accès nécessaires à l'exécution d'une fonction spécifique.

Par défaut, aucun rôle (ou rôle de cluster) RBAC Kubernetes n'est affecté aux utilisateurs. Avant d'essayer de créer un rôle (ou un rôle de cluster), vous devez disposer d'un rôle (ou d'un rôle de cluster) offrant les privilèges appropriés. Certains de ces rôles et rôles de cluster sont toujours créés par défaut, notamment le rôle de cluster d'administrateur de cluster (pour obtenir la liste complète, reportez-vous à Rôles et liaisons de rôle par défaut dans la documentation Kubernetes). Le rôle de cluster cluster-admin confère essentiellement les privilèges de superutilisateur. Un utilisateur disposant du rôle de cluster cluster-admin peut exécuter n'importe quelle opération sur l'ensemble des espaces de noms d'un cluster donné.

Reportez-vous à A propos du contrôle d'accès et du moteur Kubernetes (OKE).