Container Compute Service:Security system overview

Gestion des politiques

ACS gère les politiques via le contrôleur d'admission Gatekeeper, qui s'appuie sur les politiques Open Policy Agent (OPA). Quatre bibliothèques de règles prédéfinies sont incluses : Compliance, Infra, K8s-general et PSP. Activez ou personnalisez les politiques de sécurité dans la console pour valider la conformité des demandes de création et de mise à jour de Pods, et bloquez automatiquement les charges de travail non conformes lors du déploiement.

Pour plus d'informations, consultez Configurer les politiques de sécurité des conteneurs. Pour obtenir des détails sur chaque bibliothèque de règles, reportez-vous à Politiques de sécurité prédéfinies d'ACS.

Politiques réseau

ACS offre un contrôle d'accès réseau basé sur Kubernetes NetworkPolicy. Restreignez le trafic entrant et sortant des Pods au niveau de l'adresse IP ou du port afin d'autoriser uniquement les chemins d'accès requis par vos charges de travail, ce qui réduit la surface de mouvement latéral au sein du cluster.

Une fois les politiques réseau activées, configurez les règles pour des applications spécifiques dans la console ou à l'aide de kubectl. Pour en savoir plus, consultez Utiliser les politiques réseau dans les clusters ACS.

Conteneurs sécurisés (bac à sable sécurisé)

Le bac à sable sécurisé est un runtime de conteneur alternatif qui exécute les charges de travail dans une machine virtuelle légère dotée d'un noyau indépendant. Cette architecture offre une isolation de sécurité plus robuste que les conteneurs standards, ce qui la rend adaptée à l'isolation des applications non fiables, à l'isolation des pannes, à l'isolation des performances et à la séparation des charges de travail multi-locataires. Le bac à sable sécurisé engendre une surcharge de performance minimale et procure la même expérience opérationnelle que les conteneurs Docker, notamment en matière de journalisation, de surveillance et de mise à l'échelle automatique.

Inspection de sécurité

Les développeurs d'applications doivent respecter le principe du moindre privilège lors de la configuration des modèles de déploiement, car les attaquants exploitent souvent les privilèges inutiles accordés à un Pod pour s'échapper du conteneur. ACS inspecte la configuration de sécurité des applications en cours d'exécution afin que vous puissiez identifier les risques de configuration en temps réel.

Les résultats de l'inspection sont présentés sous forme de rapports expliquant chaque élément analysé et fournissant des suggestions de correction. Vous pouvez également planifier des inspections périodiques et stocker les résultats dans un Logstore Simple Log Service (SLS). Pour plus d'informations, consultez security-inspector.

Signature d'images

Container Registry prend en charge un mécanisme de confiance du contenu qui permet aux créateurs d'images d'appliquer une signature numérique à chaque image. Avant le déploiement, ACS vérifie les signatures d'images pour garantir que seules les images de confiance s'exécutent dans le cluster. Cela empêche l'introduction de code inattendu ou malveillant dans votre environnement et rend les images d'applications traçables tout au long du processus de déploiement.

Analyse d'images

Container Registry analyse toutes les images de conteneurs basées sur Linux pour détecter les vulnérabilités connues et fournit des évaluations de vulnérabilité ainsi que des suggestions de correctifs afin de réduire les risques de sécurité. Le moteur d'analyse de sécurité cloud intégré identifie les vulnérabilités système, les vulnérabilités applicatives et les échantillons malveillants présents dans les images.

Chaînes de livraison d'applications cloud-native (DevSecOps)

Container Registry propose une chaîne de livraison d'applications cloud-native pour une distribution de conteneurs sécurisée et efficace. Utilisez-la pour configurer la construction d'images, l'analyse d'images, la synchronisation globale d'images et le déploiement d'images, ainsi que pour définir des politiques de sécurité granulaires, réalisant ainsi une livraison entièrement observable et traçable. Le code soumis une seule fois est distribué de manière sécurisée et déployé efficacement dans plusieurs régions, faisant évoluer votre pipeline DevOps vers le DevSecOps. Pour plus d'informations, consultez Créer une chaîne de livraison.

Sécurité par défaut

ACS durcit les nœuds de cluster et les composants du plan de contrôle conformément aux benchmarks CIS Kubernetes. Tous les composants système sont durcis selon les meilleures pratiques de sécurité des conteneurs, garantissant que les images des composants système ne contiennent aucune vulnérabilité critique Common Vulnerabilities and Exposures (CVE).

Les nœuds de travail des clusters managés fonctionnent selon le principe du moindre privilège. Les utilisateurs Resource Access Management (RAM) ne reçoivent que les autorisations minimales nécessaires pour accéder aux autres ressources cloud. Pour plus d'informations, consultez Meilleures pratiques en matière d'autorisation.

Gestion des identités

Toutes les communications entre les composants du cluster ACS nécessitent une vérification par certificat TLS, sécurisant ainsi la transmission des données dans l'ensemble du cluster. ACS renouvelle automatiquement les certificats des composants système du cluster. Les utilisateurs et rôles RAM peuvent obtenir un fichier kubeconfig pour se connecter au serveur API du cluster via la console ou OpenAPI. Pour les opérations spécifiques, consultez Obtenir le KubeConfig du cluster et se connecter au cluster à l'aide de kubectl. ACS conserve les informations d'identité dans les identifiants d'accès et peut révoquer ces identifiants si nécessaire. Pour les opérations spécifiques, consultez Révoquer un fichier kubeconfig de cluster.

Contrôle d'accès granulaire

ACS met en œuvre le contrôle d'accès aux ressources Kubernetes à l'aide du contrôle d'accès basé sur les rôles (RBAC), une mesure fondamentale de durcissement pour la sécurité des applications. La page Authorizations de la console offre une autorisation RBAC granulaire au niveau du namespace, notamment :

• Modèles d'autorisations RBAC : Modèles prédéfinis pour les rôles d'administrateur, d'exploitation et de développeur, adaptés à différents besoins en matière d'autorisations.

• Autorisation groupée : Prend en charge l'autorisation groupée sur plusieurs clusters et plusieurs utilisateurs RAM.

• Rôles RAM : Prend en charge l'autorisation pour les rôles RAM.

• ClusterRoles personnalisés : Permet de lier des utilisateurs à des ClusterRoles personnalisés au sein du cluster. Pour plus d'informations, consultez Configurer les autorisations RBAC pour les utilisateurs RAM ou les rôles RAM.

Audit

ACS est intégré à SLS pour collecter, interroger et visualiser les journaux d'audit du serveur API du cluster. Utilisez ces journaux pour enregistrer et suivre les opérations quotidiennes des utilisateurs du cluster, et configurez des alertes en temps réel pour les opérations sur des types de ressources spécifiques. Pour plus d'informations, consultez Utiliser la fonction d'audit du serveur API du cluster.

Chiffrement des Secrets

Par défaut, les Secrets Kubernetes sont stockés dans etcd avec un encodage uniquement en Base64, sans chiffrement. Dans les clusters ACS, vous pouvez chiffrer les Secrets à l'aide de clés gérées par Alibaba Cloud Key Management Service (KMS), protégeant ainsi les données sensibles des applications sur le disque. La prise en charge des clés à rotation automatique est également assurée. Pour plus d'informations, consultez Utiliser Alibaba Cloud KMS pour chiffrer les secrets au repos.