2.10. Sécuriser la plate-forme de conteneurs
Les API d'OpenShift Container Platform et de Kubernetes sont essentielles pour automatiser la gestion des conteneurs à grande échelle. Les API sont utilisées pour :
- Valider et configurer les données pour les pods, les services et les contrôleurs de réplication.
- Effectuer la validation du projet sur les demandes entrantes et invoquer les déclencheurs sur d'autres composants majeurs du système.
Les fonctionnalités liées à la sécurité dans OpenShift Container Platform qui sont basées sur Kubernetes comprennent :
- Multitenancy, qui combine les contrôles d'accès basés sur les rôles et les politiques de réseau pour isoler les conteneurs à plusieurs niveaux.
- Les plugins d'admission, qui forment des frontières entre une API et ceux qui font des demandes à l'API.
OpenShift Container Platform utilise des opérateurs pour automatiser et simplifier la gestion des fonctions de sécurité au niveau de Kubernetes.
2.10.1. Isolement des conteneurs avec multitenancy
La multitenance permet aux applications d'un cluster OpenShift Container Platform appartenant à plusieurs utilisateurs et s'exécutant sur plusieurs hôtes et espaces de noms de rester isolées les unes des autres et des attaques extérieures. Vous obtenez la multitenance en appliquant le contrôle d'accès basé sur les rôles (RBAC) aux espaces de noms Kubernetes.
Dans Kubernetes, namespaces sont des zones où les applications peuvent s'exécuter de manière distincte des autres applications. OpenShift Container Platform utilise et étend les espaces de noms en ajoutant des annotations supplémentaires, y compris l'étiquetage MCS dans SELinux, et en identifiant ces espaces de noms étendus comme projects. Dans le cadre d'un projet, les utilisateurs peuvent gérer leurs propres ressources de cluster, y compris les comptes de service, les politiques, les contraintes et divers autres objets.
Les objets RBAC sont assignés aux projets afin d'autoriser les utilisateurs sélectionnés à accéder à ces projets. Cette autorisation prend la forme de règles, de rôles et de liaisons :
- Les règles définissent ce qu'un utilisateur peut créer ou accéder dans un projet.
- Les rôles sont des ensembles de règles que vous pouvez lier à des utilisateurs ou à des groupes sélectionnés.
- Les liaisons définissent l'association entre les utilisateurs ou les groupes et les rôles.
Les rôles et fixations RBAC locaux rattachent un utilisateur ou un groupe à un projet particulier. Le système RBAC de grappe permet d'attribuer des rôles et des liaisons à l'échelle de la grappe à tous les projets de la grappe. Il existe des rôles de cluster par défaut qui peuvent être attribués pour fournir un accès à admin, basic-user, cluster-admin et cluster-status.
2.10.2. Protéger le plan de contrôle avec des plugins d'admission
Alors que RBAC contrôle les règles d'accès entre les utilisateurs, les groupes et les projets disponibles, admission plugins définit l'accès à l'API principale d'OpenShift Container Platform. Les plugins d'admission forment une chaîne de règles qui se compose de :
- Plugins d'admission par défaut : Ils mettent en œuvre un ensemble de politiques et de limites de ressources par défaut qui sont appliquées aux composants du plan de contrôle d'OpenShift Container Platform.
- Les plugins d'admission mutants : Ces plugins étendent dynamiquement la chaîne d'admission. Ils font appel à un serveur webhook et peuvent à la fois authentifier une demande et modifier la ressource sélectionnée.
- Les plugins de validation d'admission : Ils valident les demandes pour une ressource sélectionnée et peuvent à la fois valider la demande et s'assurer que la ressource n'est pas modifiée à nouveau.
Les demandes d'API passent par les modules d'admission en chaîne, tout échec en cours de route entraînant le rejet de la demande. Chaque plugin d'admission est associé à des ressources particulières et ne répond qu'aux demandes concernant ces ressources.
2.10.2.1. Contraintes du contexte de sécurité (SCC)
Vous pouvez utiliser security context constraints (SCC) pour définir un ensemble de conditions qu'un pod doit remplir pour être accepté dans le système.
Certains aspects peuvent être gérés par les CSC :
- Exécution de conteneurs privilégiés
- Capacités dont un conteneur peut demander l'ajout
- Utilisation des répertoires de l'hôte comme volumes
- Contexte SELinux du conteneur
- ID de l'utilisateur du conteneur
Si vous disposez des autorisations nécessaires, vous pouvez modifier les règles par défaut de la CSC pour les rendre plus permissives, le cas échéant.
2.10.2.2. Attribution de rôles aux comptes de service
Vous pouvez attribuer des rôles aux comptes de service, de la même manière que les utilisateurs se voient attribuer un accès basé sur des rôles. Trois comptes de service sont créés par défaut pour chaque projet. Un compte de service :
- est limité à un projet particulier
- tire son nom de son projet
- se voit automatiquement attribuer un jeton API et des informations d'identification pour accéder à l'OpenShift Container Registry
Les comptes de service associés aux composants de la plate-forme font automatiquement l'objet d'une rotation de leurs clés.
2.10.3. Authentification et autorisation
2.10.3.1. Contrôler l'accès à l'aide d'OAuth
Vous pouvez utiliser le contrôle d'accès à l'API via l'authentification et l'autorisation pour sécuriser votre plateforme de conteneurs. Le master OpenShift Container Platform comprend un serveur OAuth intégré. Les utilisateurs peuvent obtenir des jetons d'accès OAuth pour s'authentifier auprès de l'API.
En tant qu'administrateur, vous pouvez configurer OAuth pour vous authentifier à l'aide d'un identity provider, tel que LDAP, GitHub ou Google. Le fournisseur d'identité est utilisé par défaut pour les nouveaux déploiements d'OpenShift Container Platform, mais vous pouvez le configurer au moment de l'installation initiale ou de la post-installation.
2.10.3.2. Contrôle et gestion de l'accès à l'API
Les applications peuvent avoir plusieurs services API indépendants qui ont des points d'extrémité différents nécessitant une gestion. OpenShift Container Platform inclut une version conteneurisée de la passerelle API 3scale afin que vous puissiez gérer vos API et en contrôler l'accès.
3scale vous offre une variété d'options standard pour l'authentification et la sécurité de l'API, qui peuvent être utilisées seules ou en combinaison pour émettre des informations d'identification et contrôler l'accès : clés API standard, ID d'application et paire de clés, et OAuth 2.0.
Vous pouvez restreindre l'accès à des points finaux, méthodes et services spécifiques et appliquer une politique d'accès à des groupes d'utilisateurs. Les plans d'application vous permettent de définir des limites de taux pour l'utilisation de l'API et de contrôler le flux de trafic pour des groupes de développeurs.
Pour un tutoriel sur l'utilisation d'APIcast v2, la passerelle API 3scale conteneurisée, voir Running APIcast on Red Hat OpenShift dans la documentation 3scale.
2.10.3.3. Red Hat Single Sign-On
Le serveur Red Hat Single Sign-On vous permet de sécuriser vos applications en fournissant des capacités d'authentification unique sur le Web basées sur des normes, y compris SAML 2.0, OpenID Connect et OAuth 2.0. Le serveur peut agir en tant que fournisseur d'identité (IdP) basé sur SAML ou OpenID Connect, en servant de médiateur avec l'annuaire des utilisateurs de votre entreprise ou un fournisseur d'identité tiers pour les informations d'identité et vos applications à l'aide de jetons basés sur les normes. Vous pouvez intégrer Red Hat Single Sign-On avec des services d'annuaire basés sur LDAP, y compris Microsoft Active Directory et Red Hat Enterprise Linux Identity Management.
2.10.3.4. Console web sécurisée en libre-service
OpenShift Container Platform fournit une console web en libre-service pour s'assurer que les équipes n'accèdent pas à d'autres environnements sans autorisation. OpenShift Container Platform garantit un maître multitenant sécurisé en fournissant les éléments suivants :
- L'accès au maître utilise la sécurité de la couche de transport (TLS)
- L'accès au serveur API utilise des certificats X.509 ou des jetons d'accès OAuth
- Le quota du projet limite les dégâts qu'un jeton malhonnête pourrait causer
- Le service etcd n'est pas exposé directement au cluster
2.10.4. Gestion des certificats pour la plate-forme
OpenShift Container Platform a plusieurs composants dans son cadre qui utilisent la communication HTTPS basée sur REST en tirant parti du cryptage via des certificats TLS. Le programme d'installation d'OpenShift Container Platform configure ces certificats lors de l'installation. Certains composants principaux génèrent ce trafic :
- maîtres (serveur API et contrôleurs)
- etcd
- nœuds
- registre
- routeur
2.10.4.1. Configuration des certificats personnalisés
Vous pouvez configurer des certificats de service personnalisés pour les noms d'hôte publics du serveur API et de la console web lors de l'installation initiale ou lors du redéploiement des certificats. Vous pouvez également utiliser une autorité de certification personnalisée.
Ressources supplémentaires
- Introduction à OpenShift Container Platform
- Utilisation de RBAC pour définir et appliquer des autorisations
- A propos des plugins d'admission
- Gestion des contraintes liées au contexte de sécurité
- Commandes de référence du CCN
- Exemples d'attribution de rôles aux comptes de service
- Configuration du serveur OAuth interne
- Comprendre la configuration du fournisseur d'identité
- Types de certificats et descriptions
- Certificats de procuration
