Nous allons vous montrer comment utiliser Kubernetes CRD pour automatiser la sécurité et protéger vos applications.Traduction de l'équipe du magazine Tomorrow Cloudy Mail.ru Cloud Solutions . Source: Niteen Kole Comment automatiser la sécurité des conteneurs en utilisant des CRD pour obtenir une stratégie de sécurité sous forme de code avec des extras .Pourquoi avez-vous besoin de CRD
La sécurité est depuis longtemps un casse-tête pour les équipes DevOps . Les outils logiciels existants résolvent avec succès les problèmes d'automatisation de l'assemblage et du déploiement des applications - le déploiement automatique des applications basées sur des conteneurs est devenu la norme. Dans le même temps, l'automatisation des paramètres de sécurité est loin derrière.Vous pouvez implémenter une analyse automatisée des vulnérabilités, mais la nécessité de configurer manuellement les politiques de sécurité des applications devient un casse-tête.L'introduction des définitions de ressources personnalisées (CRD) Kubernetes aidera à résoudre les problèmes liés à la définition de politiques de sécurité en tant que code au stade initial de l'assemblage et du déploiement d'applications, et automatisera leur utilisation lors du déploiement d'applications dans l'environnement de production.CRD peut être utilisé pour implémenter des politiques de sécurité globales qui définissent le comportement des applications et configurent la sécurité de plusieurs clusters Kubernetes utilisés.En utilisant CRD pour l'automatisation et en définissant les paramètres de sécurité de manière centralisée en tant que code, vous pouvez simultanément resserrer les paramètres de sécurité et simplifier leur application. Cela conduit finalement à des applications plus efficaces, avec moins d'erreurs et, surtout, plus sûres.Comment fonctionne CRD?
Pour définir les politiques de sécurité, nous utiliserons NeuVector CRD dans la plate -forme de conteneurs NeuVector . Alternatives à NeuVector pour la sécurité des conteneurs: AquaSec, StackRox, Sysdig Secure, Twistlock.NeuVector CRD contient des politiques qui collectent d'abord un profil complet du comportement normal des applications.Le comportement collecté est ajouté à la liste blanche, y compris toutes les règles réseau, les processus, les protocoles et les opérations sur les fichiers. Tout cela constitue un ensemble d'opérations d'application standard. Ensuite, les paramètres de sécurité sont appliqués, autorisant uniquement les connexions réseau confirmées à l'intérieur des conteneurs qui composent l'application. Ces connexions sont identifiées lors de l'inspection de la couche 7 du modèle OSI (couche de protocole d'application). Ainsi, toute tentative de connexion externe non autorisée sera empêchée.Les politiques de sécurité empêcheront les attaquants d'utiliser les communications à l'extérieur ou à l'intérieur des conteneurs pour utiliser l'application à leurs propres fins.CRD vous permet de définir des règles globales et des règles pour chaque service séparément. Les CRD sont également compatibles avec Kubernetes RBAC, vous permettant d'utiliser des comptes de service et des rôles Kubernetes pour appliquer des politiques de sécurité.De plus, le contrôle de version est disponible pour créer ses propres stratégies pour chaque version de l'application; l'intégration avec les outils de gestion des stratégies de sécurité tels que l' Open Policy Agent est prise en charge . Les clusters Kubernetesprêts à l' emploi avec un système de surveillance spécialement adapté basé sur Prometheus et Grafana, ainsi que TLS et RBAC pour la gestion des droits d'accès et la normalisation du développement dans les équipes distribuées, peuvent être testés gratuitement dans le cloud Mail.ru Cloud Solutions.Création de NeuVector CRD
NeuVector CRD vous permet d'utiliser des fichiers natifs YAML Kubernetes pour créer des règles de sécurité.Créez un fichier nvsecurityrule.yaml contenant une description de NeuVector CRD. Ce fichier contrôle NvSecurityRulela nature namespacedet NvClusterSecurityRulele cluster.apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: nvsecurityrules.neuvector.com
spec:
group: neuvector.com
names:
kind: NvSecurityRule
listKind: NvSecurityRuleList
plural: nvsecurityrules
singular: nvsecurityrule
scope: Namespaced
version: v1
versions:
— name: v1
served: true
storage: true
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: nvclustersecurityrules.neuvector.com
spec:
group: neuvector.com
names:
kind: NvClusterSecurityRule
listKind: NvClusterSecurityRuleList
plural: nvclustersecurityrules
singular: nvclustersecurityrule
scope: Cluster
version: v1
versions:
— name: v1
served: true
storage: true
Pour créer un CRD, exécutez:$ kubectl create -f nvsecurityrule.yaml
Dès que le CRD NeuVector est créé, toutes les ressources créées ultérieurement avec le paramètre kind: NvSecurityRuleseront traitées par ce CRD. Ainsi, vous pouvez créer vos propres ressources avec des politiques de sécurité connectées. Avant de faire quoi que ce soit, il est conseillé d'étudier la documentation NeuVector et d'ajouter les éléments nécessaires clusterroleset clusterrolebindings.En outre, l'utilisation de ce CRD pour appliquer des politiques de sécurité NeuVector dans un cluster Kubernetes nécessite des paramètres de droits appropriés (RBAC). Les politiques de sécurité définies par CRD pour tout espace de noms ne peuvent être appliquées que par un utilisateur qui a le droit de se déployer sur l'espace de noms spécifié. L'application de stratégies de sécurité à un cluster nécessite des privilèges d'administrateur de cluster.Ci-dessous est un morceau de code de test de demo-security-v1.yaml, qui restreint les conteneurs nginx-poddans l'espace demode noms en fournissant l'accès aux autres conteneurs du même espace de noms uniquement via HTTP.apiVersion: v1
items:
- apiVersion: neuvector.com/v1
kind: NvSecurityRule
metadata:
name: nv.nginx-pod.demo
spec:
egress:
— Selector:
criteria:
— key: service
op: =
value: node-pod.demo
— key: domain
op: =
value: demo
name: nv.node-pod.demo
action: allow
applications:
- HTTP
name: nv.node-pod.demo-egress-0
ports: any
— Selector:
criteria:
— key: service
op: =
Sous l'extrait de code doit être une description de toutes les connexions réseau autorisées aux conteneurs dans l'espace de noms demo, par exemple, les connexions au serveur redis, ainsi que les processus et l'activité du disque autorisés pour chaque conteneur. N'oubliez pas de déployer d'abord les politiques de sécurité NeuVector puis de déployer l'application. Ainsi, les politiques de sécurité seront efficaces dès le démarrage de l'application.Pour appliquer une politique de sécurité:$ kubectl create -f demo-security-v1.yaml
NeuVector lit les politiques de sécurité dans les ressources créées et utilise l'API REST pour contacter le contrôleur NeuVector, qui crée les règles et les configurations conformément aux politiques de sécurité transférées.Options pour appliquer des politiques de sécurité en tant que code
L'utilisation de politiques de sécurité comme code ouvre de nombreuses opportunités pour les commandes et les programmeurs DevOps / DevSecOps. Voici quelques exemples.Développement et test de manifestes de sécurité au stade initial des applications de construction
Les développeurs peuvent utiliser CRD pour rendre l'application plus sûre dans les premiers stades de développement. Ils peuvent simultanément faire des manifestes pour déployer et appliquer des politiques de sécurité.Après avoir assemblé l'image, vérifié automatiquement les vulnérabilités et approuvé par l'équipe DevOps, DevOps peut vérifier les deux manifestes et faire des recommandations à l'équipe de développement du point de vue de la sécurité. De nouvelles applications seront déployées avec des politiques de sécurité efficaces du premier déploiement à la production.
Utilisation de l'analyse comportementale pour créer des politiques de sécurité
Les équipes DevOps peuvent utiliser les capacités d'analyse comportementale de NeuVector dans des environnements de test pour développer des politiques de sécurité et créer des fichiers yaml adaptés à une utilisation dans NeuVector CRD.La figure suivante, à partir du coin inférieur droit du diagramme, montre comment votre équipe DevOps déploie l'application dans un environnement de test, où une analyse complète du comportement de l'application est effectuée et des profils de sécurité pour le réseau, l'activité des fichiers et les processus sont formés.Ces règles sont exportées et transmises aux développeurs qui effectuent les ajustements nécessaires et à DevOps, qui les testent avant de les utiliser en production.
Politiques de sécurité globale
NeuVector CRD vous permet de définir des politiques de sécurité globales qui ne sont liées ni à une application particulière ni à un groupe d'applications dans un cluster. Par exemple, votre équipe de sécurité ou de déploiement peut définir des règles de réseau globales pour bloquer toutes les connexions dans tous les conteneurs ou pour configurer l'accès de surveillance à tous les processus du cluster.
En utilisant conjointement les politiques de sécurité communes et les politiques de sécurité des applications, vous pouvez créer des paramètres de sécurité complexes et précis dont votre organisation a besoin.Voici un exemple d'interdiction des connexions ssh des conteneurs vers l'extérieur:- apiVersion: neuvector.com/v1
kind: NvClusterSecurityRule
metadata:
name: containers
namespace: default
spec:
egress: []
file: []
ingress:
— Selector:
criteria: []
name: external
action: deny
applications:
- SSH
name: containers-ingress-0
ports: tcp/22
process:
— action: deny
name: ssh
path: /bin/ssh
target:
Selector:
criteria:
— key: container
op: =
value: '*'
name: containers
policymode: null
version: v1
Migration des politiques de sécurité du test vers la production
Avec NeuVector CRD, vous pouvez contrôler la migration automatique des politiques de sécurité - toutes ou uniquement celles dont vous avez besoin - de l'environnement de test vers l'environnement de production. Dans la console NeuVector, vous pouvez configurer le mode de nouveaux services pour la détection, la surveillance ou la protection.Le choix d'un mode de surveillance ou de protection signifie que toute mise à jour de déploiement ou de service comprendra nécessairement la définition des politiques de sécurité que vous définissez. Ainsi, le service n'entrera en état actif qu'après l'application des politiques de sécurité.En utilisant les capacités de Kubernetes CRD et les politiques de sécurité comme code, vos développeurs et DevOps pourront appliquer l'automatisation des politiques de sécurité pour les applications et être sûr que les applications sont beaucoup mieux protégées à toutes les étapes: du début du développement au travail en production.