Slides du meetup devops aix-marseille d'ocotbre 2023
•Télécharger en tant que PPTX, PDF•
0 j'aime•167 vues
Pour ce mois d'octobre, nous vous avons préparé un programme que nous espérons incroyable : - La sécurité Kube à tous les étages par Hervé Fontbonne, consultant Cloud et DevOps (Les Filles & Les Garçons de la Tech) - Des superpouvoirs dans kube par Matthis Holleville, Principal Cloud Engineer (Agicap) et mainteneur du projet k8sgpt.ai Ces présentations seront suivies d'un rapide jeu et du traditionnel apéro ! Merci encore une fois à FGTech de nous accueillir pour cet événement
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Slides du meetup devops aix-marseille d'ocotbre 2023
Similaire à Slides du meetup devops aix-marseille d'ocotbre 2023 (20)
Plus de Frederic Leger
Plus de Frederic Leger (20)
Slides du meetup devops aix-marseille d'ocotbre 2023
- 1. En octobre, ils distribuent des châtaignes ! Ordinary October 26/10/2023
- 2. Un grand merci à
- 3. Qui sommes-nous ? Hervé Fontbonne Matthis Holleville
- 4. I. Intro II. La sécurité kube à tous les étages III. Des superpouvoirs dans kube IV. Jeu + goodies V. Apéro / Buffet Sommaire
- 5. La sécurité kube à tous les étages
- 6. Qui suis-je ? Hervé FONTBONNE Co-fondateur: Les filles et les garçons de la Tech ● Consultant Cloud et DevOps ● Formateur @HerveFONTBONNE herve@fgtech.fr
- 7. Au programme
- 8. Sécurité : Quelques principes généraux
- 9. Le réseau Diviser pour mieux régner
- 10. Réseau : “Diviser pour mieux régner”
- 11. Les noeuds Réduire la surface d’attaque Hardening Benchmark et mise à jour Sauvegarde ETCD
- 12. Node: Réduire la surface d’attaque
- 13. Node: Réduire la surface d’attaque
- 14. Node: Hardening
- 15. Node: Linux Security Modules
- 16. Node: Benchmark et Mise à jour kube bench Neuvector kubescape
- 17. Node: Benchmark et Mise à jour kube bench Neuvector kubescape
- 18. Le cluster Network Policies Authentification Tierce Role Based Access Control (RBAC) Kubernetes Policies Audit Logs
- 19. Network Policies apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: access-nginx namespace: demo spec: podSelector: matchLabels: app: nginx policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: access: "true"
- 20. Network Policies : Démo Mise en place pas à pas Tout interdire ou presque Règles adaptées Outil: Inspecktor Gadget
- 21. API Server - Authentification Tierce Pas de gestion de (vrais) utilisateurs. Les applications et les démons utilisent des ServiceAccounts. Utilisation d’une solution IAM avec une authentification tierce de type OIDC + RBAC
- 22. RBAC - Roles Based Access Control apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: demo rules: - verbs: ["get","watch","list"] apiGroups: [""] resources: ["pods"] apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: demo subjects: - kind: User name: alice apiGroup: rbac.authorization.k8s.io roleRef: kind: Role apiGroup: rbac.authorization.k8s.io name: pod-reader Alice a le droit de lister les conteneurs dans le namespace demo, mais pas de les supprimer ni les créer Outils: KubiScan, krane
- 24. Kubernetes Policy: Kyverno Catalogue de Policies Kyverno Établit votre cadre de bonnes pratiques dans vos clusters Kubernetes
- 25. Kyverno : Démo 2 Cluster Policies : - Pour autoriser uniquement certains Registries d’image - Interdire les images non taguées ou en latest Outil: Policy Reporter (Interface graphique à côté de Kyverno) Comportement en fonction de la validationFailureAction : audit et enforce
- 26. Audit logs
- 27. Les pods Gestion des données sensibles Sécuriser le contexte d’exécution Détecter les comportements anormaux
- 28. Gestion des données sensibles
- 30. Prévention : SecurityContext Permet de restreindre le contexte d’exécution des Pods et des containers. securityContext: readOnlyRootFilesystem: true allowPrivilegeEscalation: false runAsNonRoot: true runAsUser: 1000 runAsGroup: 3000 capabilities: drop: - ALL add: - NET_ADMIN
- 31. Détection - Falco - rule: Detect bash in a container desc: You shouldn't have a shell run in a container condition: container.id != host and proc.name = bash output: Bash ran inside a container (user=%user.name command=%proc.cmdline %container.info) priority: INFO
- 32. Détection - Falco / FalcoSidekick https://sysdig.com/opensource/falco/
- 33. Remédiation : Réponses aux alertes ! Outil: FalcoSideKick
- 34. Les images / containers De bonnes bases Le strict nécessaire Pas de super pouvoirs Scan des CVE
- 35. Image de base / Hiérarchie d’image
- 36. Réduire l'empreinte de vos images ● Supprimer les packages inutiles à l'exécution (chmod, chown, cron, package manager…) ● Restreindre : User Non Root ● Auditer les permissions des fichiers et dossiers RUN groupadd -g 999 appgroup && useradd -r -u 999 -g appgroup appuser USER appuser “Un processus dans un container n’est pas (très) différent d’un autre processus Linux de l’hôte”
- 37. Scan de vulnérabilité des images $> podman run aquasec/trivy image python:3.9.18-alpine3.18
- 38. Diminuer la surface d’attaque 22 octobre 2023 Size Low Medium High Critical node:20-bookworm (debian 12) Digest: sha256:a0a2fc4435b0c9ae7bec0a69b1279323a4a41c5a005581fbf30d39cd5777db37 1.1 GB 467 198 50 3 node:20-alpine3.18 Digest: sha256:002b6ee25b63b81dc4e47c9378ffe20915c3fa0e98e834c46584438468b1d0b5 182 MB 0 0 0 0 gcr.io/distroless/nodejs20-debian12 Digest: sha256:sha256:34a82884772749e5caeecd1a7895999983887ccfd41d1f33e0bac6aa555d54d8 171 MB 12 0 3 0
- 39. Le code : Dependency Check $> podman run owasp/dependency-check:$DC_VERSION CVE basés sur la National Vulnerability Database (NVD)
- 40. Observabilité ● Surveiller ce qu’il faut (ni trop, ni pas assez) ○ Logs ○ Métriques ○ Tracing ● Alerter ● Automatiser la réponse à certains évènements “La casserole qu'on surveille ne déborde jamais.” Sagesse indienne
- 41. PRA: plan de reprise d’activité Anticiper les risques et limiter les impacts liés à la survenance d’un sinistre: ● Backup / automatisation ● Procédures rédigées et testées ! “Ne rien planifier, c'est planifier son échec”
- 42. “Acheté par Suse et Open Sourcé depuis 2022”
- 43. Fonctionnalités ➢ IA: Apprentissage comportement Flux / Process / File System ➢ 3 modes: Discover / Monitor / Protect ➢ Cartographie des flux ➢ Scan CVE Node / Image ➢ Compliance: PCI-DSS / GDPR / HIPAA / NIST ➢ Sigstore/Cosign Verifiers ➢ Admission Controller (basique) ➢ Réponse automatisable: Quarantaine / Notification ➢ WAF / Data Loss Prevention (basique - Avancé = payant) Outil gratuit qui centralise les sujets sécurité Kubernetes ➢ Utilisation de RAM: 4 GB de base ➢ Beaucoup de Logs… à gérer
- 44. Démo Neuvector ➢ Apprentissage des comportements normaux : Réseau et processus ➢ Gestion des règles: n’autoriser que le flux vers backend ➢ Création d’une mise en quarantaine automatique ➢ Visualisation du diagramme des flux ➢ Gestion de la quarantaine
- 45. Merci de votre attention !
- 46. QUESTIONS ?
- 47. Des superpouvoirs dans kube
- 48. Des super pouvoirs dans Kubernetes MATTHIS HOLLEVILLE @sreguys
- 49. Touche pas à ma prod
- 50. LE DEBUG SUR KUBERNETES
- 51. ET SI….
- 52. ET SI… L’IA ?
- 53. ET SI ON INVENTAIT ENSEMBLE LE SRE DU FUTUR
- 54. MAIS C’EST QUOI K8SGPT ?
- 56. L'ÉVOLUTION DE K8SGPT Alex Jones Principal Engineer AWS OpenFeature, Kpten, …
- 62. DEMO TIME
- 63. ET SI ON RENDAIT ÇA 24/7 ?
- 69. DEMO TIME
- 77. QUESTIONS ?
- 78. DevOps needs you ! ● Speakers pour les prochains meetups ● Volontaires
- 80. Let’s play !
- 81. Let’s play !
Notes de l'éditeur
- Avant de commencer, savez vous que selon un sondage redhat de 2022 : 93% des sondés ont eu au moins un incident de sécurité sur leurs environnements kubernetes les 12 dernier mois 78% ont maintenant une initiative DevSecOps en cours Sur ce constat là, on va essayer de voir ce qu’il faut ou ne faut pas faire quand on a un cluster kubernetes en production en balayant les différentes couches
- Principes globales de la sécu : Diminuer la surface d’attaque (limiter les services exposés, les outils disponibles) limiter la taille RBAC / moindre privilèges gerer les droits finement limiter les droits et les utilités ne pas avoir un super compte admin qui a le droit de tout faire Mise à jour (avoir des logiciels qui fonctionnent c’est bien, les mettre à jour c’est indispensable) Outils contrôlés et maîtrisés (communauté, patch de sécurité, projet vivant, etc …) “tout le monde doit être formé à penser “sécurité” “
- on va attaquer la couche réseau. on va s’interesserer au concept de “diviser pour mieux regner” et voir a quel point on peut appliquer cet adage à la couche réseau.
- Architecture kube plutôt que “kubernetes” avec control plane et data plane segmentée. Utilisation de vlans pour une segmentation de niveau 2. modele OSI : couche de liaison Segmentation en zone firewall distincte (ou en ACL), avec des règles bien précises. Règle de flux limitant les communications/interaction entre les deux zones logiques et entre chaque zone et l’extérieur (connexion limitée entre les nœuds eux-même, pas de connexion ssh traverse etc …) limiter les interactions / controler les interactions externes
- on monte d’un étage et on va voir 4 principes : node : la VM
- Voyons maintenant ce que l’on entend par réduire la surface d’attaque d’un noeud Utiliser des distributions linux recommandées et/ou maîtrisées, de préférence des distributions minimalistes. Désactiver toutes applications, services, librairies non utilisées. Limiter le nombre de comptes sur le nœud, supprimer les utilisateurs inutiles, pas d’utilisateurs avec le UID 0. (pour éviter les élévations de priv par usurpation de UID) Gestion du sudoer.
- Voyons maintenant ce que l’on entend par réduire la surface d’attaque d’un noeud Utiliser des distributions linux recommandées et/ou maîtrisées, de préférence des distributions minimalistes. Désactiver toutes applications, services, librairies non utilisées. Limiter le nombre de comptes sur le nœud, supprimer les utilisateurs inutiles, pas d’utilisateurs avec le UID 0. (pour éviter les élévations de priv par usurpation de UID) Gestion du sudoer.
- Voyons maintenant ce que l’on entend par réduire la surface d’attaque d’un noeud Utiliser des distributions linux recommandées et/ou maîtrisées, de préférence des distributions minimalistes. Désactiver toutes applications, services, librairies non utilisées. Limiter le nombre de comptes sur le nœud, supprimer les utilisateurs inutiles, pas d’utilisateurs avec le UID 0. (pour éviter les élévations de priv par usurpation de UID) Gestion du sudoer.
- Controle d’acces et limitations des appels systèmes vers le noyau linux AppArmor / SELinux ===> système MAC (Mandatory Access Control) AppArmor est un bouclier permettant de limiter les accès à des ressources (comme le réseau) basé sur des profiles (par exemple ce que firefox pourra faire et ce qu’il ne pourra pas faire) SELinux (Security-Enhanced Linux) conçue par la NSA. SELinux s'appuie sur un ensemble de règles (policy) pour autoriser ou interdire une opération le + user friendly Seccomp : “secure computing mode” limite les appels systèmes vers le noyau linux (read, write, exec, getpid, …)
- Utiliser et mettre en place un benchmark comme CIS. (-> a tester régulièrement) (document gratuit qui liste les bonnes pratiques d’installation et les moyens de remédier aux anomalies détectés) les Cloud provider l’ont adaptés à leurs plateforme (AKS, EKS, …) le produit kubebench, analysera votre cluster pour vous. Il ne restera plus qu’à vous référencer au rapport de CIS, pour corriger Établir une stratégie de mise à jour du nœud et des paquets critiques mise à jour quotidienne, mise à jour des paquets de sécurité en priorité, mise en place d’un rollback automatique et d’une traçabilité des paquets mis à jour. (idéalement, les patchs de sécu a mettre à jour tout les jours, mais c’est difficile pour ne pas tout casser)
- c’est important de backuper très régulièrement la base ECTD -> avoir une stratégies de versionner les backups Avoir une base régulièrement backupée regarder RKE2 ETCD snapshot
- Transition : on a vu le reseau, les machines, on va rentrer dans le vif du sujet. un cluster c’est l’ensemble des parties logiques du control plane et des data plane. en bref, kuberntes pour être rapide.
- Par défaut, dans kubernetes, tous les pods peuvent parler avec tout le monde Les “network policies”, ce sont les règles réseaux qui décrivent les interactions réseaux possibles au sein de votre cluster. Il y a deux termes à connaître quand on parle de réseau : ingress (flux entrant) egress (flux sortant) Avec kube, tout est as code. voyons un exemple de manifest. conseil: privilégier whitelist plutôt que la blacklist. j’interdis tout, et j’autorise (minim privilège) -> attention à core-dns et pendant que l’on parle du réseau : du TLS partout: tout ce qui est chiffré est plus dure à se faire voler et çà complique aussi le travail du man in the middle Vous avez peur de devoir monter des sidecars avec des certificats entre chaque pods et de gérer le renouvellement sans avoir une durée de vie infini ? mTLS ! (aka. Istio, Cilium, …)
- évidemment, vous avez pensé à protéger l'accès à votre kube-server-api : plage IP, interdire les appel anonyme et forcer le HTTPS Mais une gros défaut de kube repose par son système d’authentification par défaut pas fait pour les humains (Kubernetes does not have objects which represent normal user accounts. ) : distribution de certificat (qui ne sont pas limité dans le temps, qui pourrait se partager Ne pas distribuer de certif (pas le root) si vous n’avez pas identity provider compatible OIDC (un vieille AD…), vous pouvez utiliser : pinniped : outil simple pour sécuriser le moyen de se logger sur un cluster kubernetes keycloak : provides user federation, strong authentication, user management, fine-grained authorization, and more
- Apres l’authentification, la gestion des roles avec le RBAC permet de Donner des droits fins par types de ressource par types d'accès et De les affecter à des groupes Appliquez le principe de moindre privilège conseil : A mettre en place dès le début du cycles de développement. Plus difficile à appliquer à posteriori
- Avant d’aller plus loin, attardons nous sur l’admision controller : regardons ensemble le schema suivant PodSecurityPolicy sont déprécié avec Kubernetes 1.21, et supprimé de Kubernetes 1.25. A la place de PodSecurityPolicy, vous pourrez appliquer des restrictions à vos pods avec : Pod Security Admission des plugins tierce, que vous déploierez et configurerez vous-même Ce n’est pas comme les PodSecurityContext. Quel est la diffence en un profil de securité et un context de sécurité ? Security Contexts configure les pods et les conteneurs au runtime. Security contexts sont définis au niveau Pod et container dans le manifest du pod manifest. Security profiles sont des mécanismes du control plane qui force un paramétrage spécifique du Security Context, ainsi que d'autres paramètres connexes en dehors du contexte de sécurité
- Dans la famille des Webhook Admission controller on trouve Kyverno ou OPA Gatekeeper kiverno définit des règles de bonnes pratique de sécurité à mettre en place au pres de vos utilisateurs (IT) Pour améliorer la sécurité Et son administration Il intercepte toutes les requêtes envoyé vers l’API Server Très simple à mettre en place. Un catalogue de règles est proposé sur le site de Kyverno Permet de valider des règles dès la demande de création d’objet dans le cluster. Quelques exemples : Pas d’images “latest” Pas de User root Pas de service NodePort Obligation de request / limit etc Cela permet aussi modifier les objets à la volée ou d’en créer Ajout de configuration aux objets Duplication de secret dans les nouveaux namespaces
- Dans la famille des Webhook Admission controller on trouve Kyverno ou OPA Gatekeeper kiverno définit des règles de bonnes pratique de sécurité à mettre en place au pres de vos utilisateurs (IT) Pour améliorer la sécurité Et son administration Il intercepte toutes les requêtes envoyé vers l’API Server Très simple à mettre en place. Un catalogue de règles est proposé sur le site de Kyverno Permet de valider des règles dès la demande de création d’objet dans le cluster. Quelques exemples : Pas d’images “latest” Pas de User root Pas de service NodePort Obligation de request / limit etc Cela permet aussi modifier les objets à la volée ou d’en créer Ajout de configuration aux objets Duplication de secret dans les nouveaux namespaces
- Une fonctionnalité mal connu des clusters kuberntes : les logs audits. Attention ce n’est pas activé par défaut sur les cluster on-prem çà fournit un ensemble chronologique d’enregistrements pertinents pour la sécurité et documentant la séquence des actions dans un cluster. Le cluster audite les activités générées par les utilisateurs, par les applications qui utilisent l’API Kubernetes et par le control plane lui-même un fichier de configuration pour définir les événements à sniffer défini par : un contenu : “toutes tentatives de lister un secret” étapes : une requête a été envoyée vers l’API server, une réponse est partie… niveau de log : pour un evenement audité: j’écris rien, les métadatas de la requete, le body de la requête, la réponse de la requête https://www.udemy.com/course/certified-kubernetes-security-specialist/learn/lecture/23104592#notes section 27
- transition récap cluster : … maintenant les pods
- slide : … Ils sont chiffrés dans les solutions managés proposés par les fournisseurs de cloud. Ils existent différentes solutions pour améliorer la sécurité des données sensibles ET NE PAS GERER LES SECRETS DANS KUBE SOPS, Sealed Secret, Vault HashiCorp Vault et les solutions managés basées dessus permettent une gestions haut niveau des secrets Dans Kubernetes et autres environnements d’exécution. Il permet aussi de gérer : une Public Key Infrastructure (PKI) Connexions dynamiques aux Cloud Providers ou aux BDDs Rotation
- En 2 phrases la sécurité sur un pod pourrait se décrire en 2 phases : prévention (restreinte) security context Et comme la confiance n’exclue pas le contrôle : détection (surveiller) avec falco
- Quelques exemples de configuration du securityContext. readOnlyRootFilesystem: true Le fileSystem du container est en read Only Tout volume monté dans le conteneur aura ses propres permissions de système de fichiers. allowPrivilegeEscalation: false interdit qu’un process enfant ait plus de droits que son parent Pas compatible avec CAP_SYS_ADMIN ou privileged runAsNonRoot: true / runAsUser: 1000 / runAsGroup: 3000 Contraint l’UID / GID numérique (root: 0) lançant le process du container fsGroup: 2000 Définit le group des volumes capabilities: drop / add: définit les capabilities linux seccompProfile: type: Localhost localhostProfile: my-profiles/profile-allow.json Annotation pour appliqué un profile AppArmor sur un container : container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref> https://snyk.io/wp-content/uploads/10-Kubernetes-Security-Context-settings-you-should-understand.pdf Use the default (masked) /proc filesystem mount Do not use the host network or process space - using "hostNetwork:true" will cause NetworkPolicies to be ignored since the Pod will use its host network. Drop unused and unnecessary Linux capabilities. Use SELinux options for more fine-grained process controls. Give each application its own Kubernetes Service Account. Do not mount the service account credentials in a container if it does not need to access the Kubernetes API.
- Pareil que Kyverno, mais pour la détection, il y a un outil open source qui monte en puissance, c’est Falco Falco analyse les appels système du noyau pour fournir une visibilité de l'activité des conteneurs, des hôtes du cluster Il exploite également les événements d'audit de l'API Kubernetes. Ajout de metadata du contexte Il est préférable de l’installer sur les nodes directment pas dans le cluster Kubernetes — Architecture : core dans usernamespace : Analyse les infos, envoie les alertes Configuration : définit les règles à respecter, et quand déclencher les alertes. Un driver dans le kernel : Envoie les informations d'appel système. (Par défaut) Module noyau construit sur les bibliothèques C++ libscap et libsinsp. Sonde eBPF construite à partir des mêmes modules Falco utilise des règles pour détecter un comportement suspect. Il posséde un jeu de règles par défaut comme par exemple un bash dans notre container. Exécution d'un shell par un conteneur Montage d'un volume de l'hôte Lecture de secrets et d'informations sensibles comme /etc/shadow Installation d'un nouveau paquet sur un conteneur Apparition d'un nouveau processus ne faisant pas partie du CMD d'un conteneur Ouverture d'un nouveau port ou connexion suspecte Lecture/écriture dans des répertoires bien connus tels que /etc, /usr/bin, /usr/sbin, etc. Changements d’ownership et de mode Connexions réseau inattendues ou mutations de socket Création d'un conteneur privilégié Ce n’est qu’un outil de monitoring uniquement Il peut envoyer des alertes à un ou plusieurs channels, mais il n’effectue aucune action par lui-même… https://sysdig.com/blog/intro-runtime-security-falco/ OUTPUTS Falco: Standard Output A file Syslog A spawned program A HTTP[s] end point A client via the gRPC API
- Lié à Falco, on ajoutera “Falco Side Kick” pour la remédiation à l’aide de serverless”
- Lié à Falco, on ajoutera “Falco Side Kick” pour la remédiation à l’aide de serverless”
- transition récap cluster : … maintenant les pods
- Utiliser des images officielles reconnues Contrôler au maximum vos images Leur mise à jour Leur contenu Pour avoir le contrôle on peut créer une hiérarchie d’image En partant d’une image d’OS reconnue Image utilisée pour créer vos images middleware (java, Node etc…) Et enfin utiliser ces images middleware pour créer vos images applicatives MCO : maintien en condition opérationnelle
- transition : La hiérarchie d’image va permettre d’adapter les images à votre contexte. Du point de vue de la sécurité il faut Réduire la surface d’attaque : Réduire les binaires et librairies embarquées dans vos images, ce sont autant de portes ouvertes à des vulnérabilités. Multi stage pour embarquer dans l’image finale uniquement l’exécutable et l'environnement d’exécution. Définir un User non root pour démarrer le processus du container et adapter les permissions sur les dossiers Donner des droits root à un container, c’est exactement comme donner des droits root sur la machine host
- Malgres tous nos efforts de choix d’images de bases, il faut continuer à ne pas avoir confiance Scanner régulièrement vos images Répondre en fonction des résultats du Scan Intégration Simple dans la chaîne d’intégration Parler de signature -> trivy permet de lister des CVE connues, la criticité, les plages de présence des failles
- alpine : OS dédié au contenaire de type docker distroless : image mise à disposition par google, avec un ensemble de bonne pratique. ex: nonroot, pas de bash, …
- Comme Trivy, mais pour les dépendances applicatives de vos applications. pour chaque dependance/librairie, on a la liste des CVE + détails de la CVE + remediation (les versions infectées par la version) Attention aux faux positifs, c’est le plus compliqué. Possibilité d’exclure des CVE pour des dépendances/librairies en cas de non alerte (par ex : une faille sur l’exposition JMX mais vous n'autorisez pas l’usage du JMX dans votre contexte…) Dans une CI, ne bloquez pas en cas de détection, autorisez-vous un petit délai de remédiation (si c’est possible) Exemple de sortie : https://jeremylong.github.io/DependencyCheck/general/SampleReport.html
- transition : La hiérarchie d’image va permettre d’adapter les images à votre contexte. Du point de vue de la sécurité il faut Réduire la surface d’attaque : Réduire les binaires et librairies embarquées dans vos images, ce sont autant de portes ouvertes à des vulnérabilités. Multi stage pour embarquer dans l’image finale uniquement l’exécutable et l'environnement d’exécution. Définir un User non root pour démarrer le processus du container et adapter les permissions sur les dossiers Donner des droits root à un container, c’est exactement comme donner des droits root sur la machine host
- transition : La hiérarchie d’image va permettre d’adapter les images à votre contexte. Du point de vue de la sécurité il faut Réduire la surface d’attaque : Réduire les binaires et librairies embarquées dans vos images, ce sont autant de portes ouvertes à des vulnérabilités. Multi stage pour embarquer dans l’image finale uniquement l’exécutable et l'environnement d’exécution. Définir un User non root pour démarrer le processus du container et adapter les permissions sur les dossiers Donner des droits root à un container, c’est exactement comme donner des droits root sur la machine host
- transition : La hiérarchie d’image va permettre d’adapter les images à votre contexte. Du point de vue de la sécurité il faut Réduire la surface d’attaque : Réduire les binaires et librairies embarquées dans vos images, ce sont autant de portes ouvertes à des vulnérabilités. Multi stage pour embarquer dans l’image finale uniquement l’exécutable et l'environnement d’exécution. Définir un User non root pour démarrer le processus du container et adapter les permissions sur les dossiers Donner des droits root à un container, c’est exactement comme donner des droits root sur la machine host
- transition : La hiérarchie d’image va permettre d’adapter les images à votre contexte. Du point de vue de la sécurité il faut Réduire la surface d’attaque : Réduire les binaires et librairies embarquées dans vos images, ce sont autant de portes ouvertes à des vulnérabilités. Multi stage pour embarquer dans l’image finale uniquement l’exécutable et l'environnement d’exécution. Définir un User non root pour démarrer le processus du container et adapter les permissions sur les dossiers Donner des droits root à un container, c’est exactement comme donner des droits root sur la machine host
- Si a tout les étages vous avez suivi les conseils : Diminuer la surface d’attaque RBAC / moindre privilèges Mise à jour Outils contrôlés et maîtrisés (communauté, patch de sécurité, projet vivant, etc …) Vous pouvez mieux dormir