Le code du contrôleur d'admission est en cours de révision sur : https://github.com/kubernetes/kubernetes/pull/24600

Cette fonctionnalité passe directement à la version bêta car elle a été exposée initialement dans OpenShift.

Il sera désactivé par défaut dans kubernetes/kubernetes#24600. Après cela, nous avons besoin de changements dans le contrôleur d'admission pour lier les PSP aux utilisateurs.

Notant https://github.com/kubernetes/kubernetes/pull/20573 comme dépendance pour la prochaine étape sur PSP (accès au niveau du sujet)

Quel est le statut de cela ? La description dans le premier commentaire est-elle à jour ?

La description dans le premier commentaire est-elle à jour

non (je n'ai pas les autorisations pour mettre à jour). Je crois que toutes les exigences alpha ont été remplies. Les types, api et tests initiaux ont été fusionnés. Le contrôleur d'admission n'est pas activé par défaut.

IMO, le travail restant pour beta/1.4 est l'intégration auth pour les autorisations, la mise à jour pour les nouveaux champs que nous voulons contraindre (seccomp - en cours, sysctl), et tous les docs/tutoriels requis.

Et un test e2e.

Le mardi 12 juillet 2016 à 6h23, Paul Weil [email protected] a écrit :

La description dans le premier commentaire est-elle à jour

non (je n'ai pas les autorisations pour mettre à jour). Je crois que tout l'alpha
exigences ont été respectées. Les types, API et tests initiaux ont été
fusionné. Le contrôleur d'admission n'est pas activé par défaut.

IMO le travail restant pour beta/1.4 est l'intégration auth pour les permissions,
mise à jour pour les nouveaux champs que nous voulons contraindre (seccomp - en cours,
sysctl) et tous les documents/tutoriels requis.

—
Vous recevez ceci parce que vous êtes l'auteur du fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/features/issues/5#issuecomment -232045429,
ou couper le fil
https://github.com/notifications/unsubscribe/AHuudqFwephlYk0Y1PS77y0xxA5QW0_-ks5qU5U7gaJpZM4IaU8n
.

Qu'en est-il des interactions avec les fournisseurs de cloud ? Ce serait bien d'attribuer facilement à chaque pod différents rôles IAM afin qu'ils puissent accéder uniquement au sous-ensemble de services cloud dont ils ont réellement besoin. Serait-ce dans la portée ou est-ce considéré comme un détail de SecurityContext ?

@therc qui devrait être fait via ServiceAccount.

@goltermann J'ai remarqué que cela était marqué avec alpha mais je pense qu'il a probablement besoin de la balise bêta basée sur https://github.com/kubernetes/features/issues/5#issuecomment -217939650

@erictune la version bêta semble-t-elle correcte d'après le commentaire @pweil- ?

@goltermann Je pense que techniquement, cela aurait été une version bêta en 1.3, ce n'est pas nouveau pour la 1.4 bien que le développement soit en cours.

Oui, la bêta est correcte. J'avais tort quand j'ai dit alpha plus tôt aujourd'hui.

super, c'est réparé

@pweil- Les documents sont-ils prêts ? Veuillez mettre à jour la documentation sur https://github.com/kubernetes/kubernetes.github.io , puis ajouter des numéros PR et cocher la case docs dans la description du problème

@janetkuo docs PR https://github.com/kubernetes/kubernetes.github.io/pull/1150

modifier : https://github.com/kubernetes/kubernetes.github.io/pull/1206 est le bon 1.4 PR

cc @kubernetes/feature-reviewers

@pweil- Je suppose que ce PR est réel - https://github.com/kubernetes/kubernetes.github.io/pull/1206 ?

correct

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme nouveau avec /remove-lifecycle stale .
Les problèmes obsolètes pourrissent après 30 jours d'inactivité supplémentaires et finissent par se fermer.

Empêchez les problèmes de se fermer automatiquement avec un commentaire /lifecycle frozen .

Si vous pouvez fermer ce problème en toute sécurité maintenant, faites-le avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou @fejta .
/ cycle de vie obsolète

des travaux sont en cours dans la 1.10 pour déplacer PSP vers son groupe d'API sans extensions
cc @php-codeur

Mises à jour de la documentation @erictune , s'il vous plaît ? Voir également [la feuille de calcul de suivi des fonctionnalités 1.10[(https://docs.google.com/spreadsheets/d/17bZrKTk8dOx5nomLrD1-93uBfajK5JS-v1o-nCLJmzE/edit#gid=0). lmk si vous avez des questions. Nous devons faire réviser et fusionner un PR de docs d'ici le 3/9. Merci!

@php-codeur ^

@Bradamant3 @liggitt Quelles mises à jour de la documentation sont nécessaires ?

Pour les modifications liées à la transition du groupe d'API, j'ai soumis : https://github.com/kubernetes/website/pull/7562 , https://github.com/kubernetes/examples/pull/206 et https:/ /github.com/kubernetes/examples/pull/208

Je ne suis pas le bon propriétaire des mises à jour PSP Doc.

Le ven. 2 mars 2018 à 11 h 26, Vyacheslav Semushin <
[email protected]> a écrit :

@Bradamant3 https://github.com/bradamant3 @liggitt
https://github.com/liggitt Quelles mises à jour de doc sont nécessaires ?

Pour les modifications liées à la transition du groupe d'API, j'ai soumis :
kubernetes/website#7562 https://github.com/kubernetes/website/pull/7562 ,
kubernetes/examples#206 https://github.com/kubernetes/examples/pull/206 ,
et kubernetes/exemples#208
https://github.com/kubernetes/examples/pull/208

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/features/issues/5#issuecomment-370026485 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AHuudtBCup17Kt91pqJzBRpKWStoXUt-ks5taZzcgaJpZM4IaU8n
.

C'est tout ce dont nous avons besoin. J'ai ajouté le PR à la feuille de calcul de suivi. Merci!

@php- coder @liggitt @tallclair
Des projets pour cela dans la 1.11 ?

Si tel est le cas, pouvez-vous vous assurer que la fonctionnalité est à jour avec les éléments suivants :

• La description
• Jalon
• Cessionnaire(s)
• Étiquettes:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

@php-coder Pouvez-vous répondre au commentaire de @justaugustus avec le travail que vous faites ici ? Y a-t-il des changements autres que le déplacement du groupe de politiques ?

Y a-t-il des changements autres que le déplacement du groupe de politiques ?

Non, je n'ai travaillé que sur ça.

J'espère que @liggitt mettra à jour la description quand il en aura le temps (car je n'ai pas les autorisations appropriées).

Fait.

@tallclair juste pour clarifier, nous suivons stable comme cible pour 1.11, n'est-ce pas ?
J'ai mis à jour l'étiquette, je veux juste m'en assurer.

Non, ce sera toujours en version bêta. Je ne suis pas sûr que PodSecurityPolicy ira un jour à stable (c'est-à-dire qu'il sera remplacé par autre chose), mais d'autres pourraient ne pas être d'accord avec moi à ce sujet.

J'ai compris. Merci pour la mise à jour, @tallclair !

@justaugustus Je supprimerai cela du jalon 1.11, car aucun progrès significatif ne se produira dans la version actuelle.

Aucune mise à jour prévue pour la 1.12

@tallclair je pourrais peut-être obtenir les boutons RunAsGroup PSP en 1.12

Acquittement. Ce sera toujours en version bêta cependant. Pour le moment, il n'est pas prévu que la PSP passe en GA. Il y a quelques problèmes majeurs d'utilisabilité qui doivent être résolus avant de progresser. (voir https://github.com/kubernetes/kubernetes/issues/60001 et https://github.com/kubernetes/kubernetes/issues/56174)

/désaffecter

/attribuer @tallclair

salut
Cette amélioration a déjà fait l'objet d'un suivi, nous aimerions donc vérifier et voir s'il est prévu que cela passe par des étapes supérieures dans Kubernetes 1.13. Cette version est destinée à être plus "stable" et aura un calendrier agressif. Veuillez n'inclure cette amélioration que s'il existe un niveau élevé de confiance dans le respect des délais suivants :

• Docs (RP ouverts d'espace réservé) : 11/8
• Code Slush : 11/9
• Le gel du code commence : 11/15
• Documents complets et révisés : 27/11

Veuillez prendre un moment pour mettre à jour les jalons de votre message d'origine pour un suivi futur et envoyer un ping à @kacole2 s'il doit être inclus dans la feuille de suivi des améliorations 1.13

Merci!

Aucun changement prévu dans la version 1.13.

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme nouveau avec /remove-lifecycle stale .
Les problèmes obsolètes pourrissent après 30 jours d'inactivité supplémentaires et finissent par se fermer.

Si vous pouvez fermer ce problème en toute sécurité maintenant, faites-le avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/ cycle de vie obsolète

/supprimer le cycle de vie obsolète

@tallclair Bonjour - Je suis responsable de l'amélioration pour la version 1.14 et je vérifie ce problème pour voir quel travail (le cas échéant) est prévu pour la version 1.14. Le gel des améliorations est le 29 janvier et je tiens à rappeler que toutes les améliorations doivent avoir un KEP

Rien de prévu pour la 1.14.

Quelles sont les lacunes pour que ce soit GA ? Je peux penser à quelques-uns, mais je ne vois aucun critère dans la description.

Avant que cela puisse passer à GA, nous devons résoudre ces problèmes :

1. Modèle d'autorisation défectueux - L'utilisation de PSP est accordée via RBAC et peut être accordée soit à l'utilisateur, soit au pod créé. L'accorder à l'utilisateur est une approche intuitive, mais problématique (voir explication). Cette approche présente également des problèmes de sécurité.
2. Difficile à déployer - Étant donné que les pods sont rejetés par défaut, nous ne pouvons pas déployer PSP sur tous les clusters sans les casser. De même, les utilisateurs qui souhaitent activer la PSP doivent s'assurer d'une couverture complète de toutes les charges de travail avant de pouvoir l'activer, ce qui la rend difficile à activer (d'où l'utilisation relativement faible). Étant donné que la fonctionnalité doit être explicitement activée, nous n'avons pas une couverture de test adéquate (la matrice de fonctionnalités est trop complexe).
3. API incohérente - Moins un problème fondamental, mais l'évolution de l'API PSP sur une longue période de versions de k8 a conduit à un certain nombre d'incohérences qui la rendent difficile à utiliser. En particulier, la mutation est regroupée avec la validation, ce qui peut entraîner des résultats inattendus lorsqu'un pod a accès à plusieurs PSP.

@liggitt et moi avons quelques idées sur la façon de résoudre ce problème, mais il reste à savoir si cela appartient au cœur de Kubernetes. J'aimerais avoir une feuille de route le mois prochain, soit un plan pour aller à GA ou un plan pour la dépréciation.

Merci pour le partage des informations!

Comme les pods sont rejetés par défaut, nous ne pouvons pas déployer PSP sur tous les clusters sans les casser.

Je suppose que ce n'est pas vraiment ça. Nous l'avons fait en créant d'abord une PodSecurityPolicy suffisamment ouverte (ou même ouverte à tous), puis en l'affinant progressivement.

@ zhouhaibing089 un utilisateur de Kubrenetes peut utiliser cette méthode qui fonctionne car il contrôle les politiques. Cependant, nous ne pouvons pas déployer cela en tant que valeur par défaut de Kubernetes, car PodSecurityPolicy n'ouvre que le cluster, ce qui signifie qu'il est très difficile de gérer le PSP tout autorisé contrôlé par le système.

Bonjour @liggitt @tallclair , je suis le responsable de l'amélioration pour 1.15. Cette fonctionnalité va-t-elle passer aux niveaux alpha/bêta/stable en 1.15 ? Veuillez me le faire savoir afin qu'il puisse être suivi correctement et ajouté à la feuille de calcul. La proposition de la communauté devra être migrée vers un KEP pour être incluse dans la version 1.15.

Une fois le codage commencé, veuillez énumérer tous les PR k/k pertinents dans ce numéro afin qu'ils puissent être suivis correctement.

Aucun changement prévu pour la 1.15

@tallclair J'adorerais vraiment voir cette terre comme GA en 1.16. Est-ce possible?

@ lachie83 Non, nous ne sommes pas sûrs de vouloir que PodSecurityPolicy aille à GA. Il n'est pas clair qu'il s'agisse d'un cas d'utilisation qui devrait être résolu par le cœur de Kubernetes, et nous étudions des alternatives hors cœur. Si vous souhaitez en discuter plus en détail, c'est un bon sujet pour SIG-Auth.

@tallclair Est-ce que des trucs comme le gardien d'Open Policy Agent seraient une meilleure voie pour descendre?

Oui, exactement. C'est peut-être le principal concurrent, et je travaille en étroite collaboration avec cette équipe pour m'assurer qu'elle couvrira ces cas d'utilisation.

La seule chose que j'attendais, c'est un outil qui pourrait potentiellement traduire PodSecurityPolicy --> politique de rego OPA. Cela les rendrait beaucoup plus faciles à déprécier de votre point de vue.

@tallclair apprécie la réponse rapide

@SEJeff a accepté. Nous n'abandonnerons pas PodSecurityPolicy tant qu'il n'y aura pas de remplacement clair avec la parité des fonctionnalités et le chemin de migration.

Hé @tallclair , vous avez mentionné une feuille de route vers GA ou un plan de dépréciation. On dirait que nous penchons vers ce dernier.

Avons-nous quelque chose d'écrit pour aider les personnes qui considèrent les PSP comme une solution à boucler la boucle ?

Pas encore. Une partie de l'hésitation est que nous ne voulons pas dire que nous le déconseillerons en faveur de quelque chose d'autre jusqu'à ce qu'il y ait un remplacement clair. Bien que je sois enthousiasmé par le gatekeeper, il n'a pas encore les fonctionnalités (ou la stabilité) dont nous avons besoin pour remplacer la PSP. Une autre possibilité est que nous puissions déplacer PSP hors de l'arborescence et l'amener à GA en tant que webhook d'admission (les 2 options ne s'excluent pas mutuellement). Cependant, nous n'avons pas encore officiellement défini de feuille de route.

Wtf

Salut @tallclair on dirait que rien ne se passe ici pour 1.16 aussi, donc je vais le garder pareil.

Hé là @tallclair - 1.17 Amélioration principale ici - il semble que cela reste tel quel pour 1.17. Si cela change, n'hésitez pas à me donner un coup de pouce et je pourrai l'ajouter à la feuille de suivi 👍

Y a-t-il eu d'autres discussions sur une voie claire pour l'avenir de la PSP ?

Oui, exactement. C'est peut-être le principal concurrent, et je travaille en étroite collaboration avec cette équipe pour m'assurer qu'elle couvrira ces cas d'utilisation.

@tallclair - nous avons mis en place la plupart des contrôles PSP à Kyverno. Pouvez-vous aider à jeter un coup d'œil? J'adorerais discuter d'idées et de détails.

https://github.com/nirmata/kyverno/blob/master/samples/README.md

Le projet Gatekeeper s'est également penché sur ce à quoi ressemblerait un monde post-PSP. Notre approche initiale a consisté à décomposer la ressource PSP en contraintes individuelles . Nous nous demandions ce que la communauté pensait de cette approche. Peut-être serait-il temps de réimaginer la composition de ces politiques ? La migration pour les nouveaux utilisateurs et les utilisateurs PSP existants sera également importante.

cc @maxsmythe @sozercan @tsandall

J'ai quelques inquiétudes quant à la décomposition des politiques en contraintes individuelles, à savoir que je dois créer beaucoup plus d'objets de contrainte. Si je pense avoir besoin de les cloner ou de les modifier pour différentes charges de travail, je crains que cela ne devienne très complexe.

Je pense que la meilleure approche serait centrée sur l'utilisateur. Si nous pouvons obtenir de vrais commentaires sur la façon dont les PSP sont utilisés, puis voir à quoi ressemblerait une configuration similaire sous ces plugins alternatifs, cela peut aider à façonner la conception.

@tallclair l'un des cas d'utilisation que nous poursuivons est lié à la multilocation basée sur l'espace de noms. L'intention est d'utiliser des stratégies pour appliquer des restrictions et garantir que les espaces de noms sont correctement configurés.

Avant que cela puisse passer à GA, nous devons résoudre ces problèmes :

1. Modèle d'autorisation défectueux - L'utilisation de PSP est accordée via RBAC et peut être accordée soit à l'utilisateur, soit au pod créé. L'accorder à l'utilisateur est une approche intuitive, mais problématique (voir explication). Cette approche présente également des problèmes de sécurité.

@tallclair , je m'interroge sur ce qui précède - pouvez-vous expliquer en quoi cette approche est problématique et/ou présente des problèmes de sécurité ?

Est-ce que quelqu'un de plus informé peut confirmer ce tweet :

https://twitter.com/TechJournalist/status/1197658440040165377

Et si c'est vrai, que devraient faire les utilisateurs de PSP pour limiter les capacités de Linux aujourd'hui ?

Salut tout le monde,
Il s'agit d'une discussion très intéressante et nous recherchons actuellement des solutions pour sécuriser la création de pods dans les clusters Kubernetes.

Nous avons examiné à la fois OPA Gatekeeper et PodSecurityPolicies, ainsi que les efforts visant à réimplémenter PSP dans les contraintes OPA.
Le problème fondamental que nous avons trouvé avec cette comparaison est que nous avons affaire à deux modèles opposés.

• OPA Gatekeeper suit le modèle ouvert par défaut, dans lequel tout est autorisé et l'administrateur interdit certaines choses avec des contraintes.
• PSP suit le modèle fermé par défaut, dans lequel tout est interdit et l'administrateur autorise certaines choses avec des politiques.

Du point de vue de la sécurité, je dirais que le modèle PSP est meilleur, bien que plus difficile à intégrer dans les clusters existants car toutes les charges de travail doivent s'y conformer.

Comment comptez-vous combler ce fossé fondamental dans l'architecture, entre la PSP et le Constraint Framework ?

/cc @ritazh J'aimerais connaître votre opinion à ce sujet, puisque vous avez travaillé sur le portage de la fonctionnalité PSP vers OPA.

Les différentes approches rendent définitivement la migration plus compliquée. Nous explorons différentes façons de rendre la transition plus fluide.

Dans un monde parfait, je conviens que tout refuser par défaut est l'approche la plus sûre. Cependant, c'est l'une des choses qui rend la PSP si difficile à utiliser et à déployer. En pratique, je pense qu'il est plus faisable de réduire progressivement les autorisations, et comme le dit le vieil adage "la meilleure sécurité est la sécurité que vous utilisez".

En passant, nous discutons également de la manière de désactiver/exclure/obtenir des exceptions aux contraintes (par exemple pour protéger l'espace de noms kube-system). Selon la façon dont cela fonctionne, vous pouvez implémenter une approche de refus par défaut en verrouillant tout, puis en accordant des exceptions. Je ne sais pas si c'est un cas d'utilisation pour lequel nous voulons concevoir ...

@tallclair vous attendez-vous à des progrès à ce sujet en 1.18 ? Je suis une ombre des améliorations pour la version et j'aimerais savoir si nous devrions suivre cela.

Aucun changement prévu pour la 1.18

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme nouveau avec /remove-lifecycle stale .
Les problèmes obsolètes pourrissent après 30 jours d'inactivité supplémentaires et finissent par se fermer.

Si vous pouvez fermer ce problème en toute sécurité maintenant, faites-le avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/ cycle de vie obsolète

/supprimer le cycle de vie obsolète

@tallclair Salut Tim. Des projets pour cela dans la 1.19 ?

Pas de plans pour la v1.19, bien que j'espère voir du mouvement dans la période v1.20.

Je viens de tomber sur les stratégies de sécurité des pods Kubernetes avec Open Policy Agent . @tallclair pouvez-vous partager ce qui nous bloque et où l'aide est nécessaire, heureux de contribuer également.

pouvez-vous partager ce qui nous bloque

Fondamentalement, nous devons juste prendre une décision sur la voie à suivre. Actuellement, je pense qu'il y a un accord sur le fait que la PSP ne devrait pas devenir GA dans sa forme actuelle, mais nous n'avons pas encore choisi de remplaçant. Options dont nous avons discuté :

1. Pas de remplacement - recommande de choisir parmi une option tierce avec un webhook d'admission. Le document sur les normes de sécurité Pod récemment publié tente de rendre cela plus fluide en promouvant des fonctionnalités équivalentes.
2. Contrôles intégrés alternatifs
   
   
   
   1. @deads2k a proposé de mettre en amont openshifts SecurityContextConstraints
   
   
   2. J'ai proposé une fonctionnalité minimalement configurable qui applique uniquement les politiques standard liées ci-dessus (et recommande une solution tierce lorsqu'une plus grande configurabilité est nécessaire)
   
   
3. Correction de la politique de sécurité du pod - Bien que certains des problèmes soient suffisamment importants pour la conception, cela devrait être non rétrocompatible, auquel cas cela pourrait aussi bien être une nouvelle alternative dans (2)

Suis-je en train de lire https://github.com/kubernetes/kubernetes/pull/90603 correctement que parce que les normes de sécurité des pods sont publiées, il n'y a pas de remplacement prévu pour les PSP dans le serveur API et tout remplacement devra être implémenté en tant que système externe ?

Voir https://github.com/kubernetes/enhancements/issues/5#issuecomment -637066475

Le calendrier d'obsolescence de la version bêta actuelle dans la version 1.22 est indépendant de la fourniture ou non d'une implémentation dans l'arborescence des profils de sécurité de pod standard. Cela n'a pas encore été déterminé.

Merci @liggitt confirmait que rien n'avait été défini. pensait à l'origine que rien ne serait obsolète jusqu'à ce qu'un remplaçant soit disponible. Il n'était pas clair si une décision avait été prise d'une manière ou d'une autre.

La chronologie de dépréciation n'est pas spécifique à PSP et a été ajoutée dans le cadre de https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta

si je lis ceci correctement, ce qui pousse à la dépréciation, c'est qu'aucune API ne devrait être dans la même version bêta pendant plus de 9 mois, donc la PSP doit être promue ou obsolète et puisqu'il n'y aura pas de nouvelles bêtas ou GA de psp il doit être sur la bonne voie pour être obsolète même si un remplacement n'a pas été décidé ?

si je lis ceci correctement, ce qui pousse à la dépréciation, c'est qu'aucune API ne devrait être dans la même version bêta pendant plus de 9 mois

exactement. toutes les futures versions bêta de toutes les API intégrées seront accompagnées d'une obsolescence et d'une cible de suppression prédéfinies lors de leur première introduction

Salut @tallclair

Améliorations Lead ici. Des projets pour cela en 1.20 ?

Merci,
Kirsten

Aucun projet pour la v1.20.

Cette situation est extrêmement frustrante pour ceux d'entre nous qui ont besoin d'exécuter des clusters de haute sécurité. Nos options sont :

1. Asseyez-vous et attendez que les PSP soient obsolètes.
2. Sous-traitez l'application de la sécurité de l'exécution de la charge de travail à un fournisseur (Styra), car OPA ne documente pas comment exécuter un remplacement PSP entièrement restrictif avec Rego.

Ainsi, mon entreprise a mis en place des PSP entièrement verrouillés. Ils ne sont pas faciles à mettre en œuvre et leur débogage est une corvée, mais ils sont très fonctionnels et fonctionnent réellement. Nous avons même publié un article de blog détaillant comment ils pourraient être utilisés de cette façon et comment gérer les exceptions lorsqu'elles se produisent.

IMO, la version bêta de la PSP devrait être fusionnée telle quelle dans le noyau principal de Kubernetes. Mes raisons sont :

1. Bien que les PSP aient des défauts, elles fonctionnent et ont fonctionné pendant 10 versions.
2. Kubernetes en tant que projet doit se soucier de la sécurité de l'exécution de la charge de travail. Les évasions de conteneurs sont beaucoup trop faciles. Les PSP sont l'un des rares outils qui rendent cela plus difficile pour les attaquants.
3. Perfect est l'ennemi de Done. Fusionnez les PSP tels quels et transférez la "meilleure" implémentation vers policy/v2.
4. Enfin, et surtout, cela permet aux développeurs OSS d'exécuter des clusters de sécurité plus élevée, pas seulement des entreprises qui peuvent se permettre des fournisseurs comme Styra.

@zapman449 pouvez-vous clarifier ce que vous entendez par "remplacement PSP totalement restrictif" ?

Espérons que la bibliothèque Gatekeeper PSP facilite l'application de règles similaires à celles utilisées par PSP. Je suis certainement intéressé par les lacunes fonctionnelles que vous voyez.

@zapman449 auriez-vous un lien vers ce blog ?

@christianhuening https://developer.squareup.com/blog/kubernetes-pod-security-policies

@maxsmythe Je n'ai pas compris ce que fait Gatekeeper PSP, je vais le revoir.

Cependant, ce que je veux dire c'est :

1. Contrôle total sur les capacités de processus telles que NET_BIND_SERVICE, SYS_ADMIN, etc.
2. Restreindre UID/GID/FSGroups à des valeurs non nulles
3. Liste explicite des chemins d'hôte pouvant être montés
4. Liste explicite des types de montages de volumes autorisés
5. Bloquer les privilèges, bloquer l'escalade des privilèges
6. Bloquer l'accès aux primitives de communication interprocessus au niveau de l'hôte
7. Bloquer l'accès au réseau hôte
8. restreindre les ports hôtes autorisés
9. Appliquer readOnlyRootFilesystem
10. Point de connexion pour SELinux

Ceux-ci sont aujourd'hui fournis avec les PSP.

Si nous demandons une liste de souhaits, j'aimerais :

1. Valeurs par défaut intelligentes pour les SysCalls des conteneurs. Il y a un petit pourcentage de la liste totale des appels système Linux dont la plupart des conteneurs ont besoin. Permettez-moi de restreindre la plupart des conteneurs à cette liste, puis permettez-moi soit d'autoriser explicitement certains appels pour certains pods appartenant à certains comptes de service, soit d'accorder carte blanche à des comptes de service spécifiques.
2. Laissez-moi rêver encore un peu, et je trouverai quelque chose. ;-)

@zapman449 - Si vous ne l'avez pas vu, nous avons discuté de l'avenir des PSP lors de la dernière réunion sig-auth (https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#heading=h.hsgtsqg83z5u ). Nous poursuivrons la discussion lors de la réunion du 9 décembre si vous êtes en mesure de le faire, mais nous ne prendrons pas non plus de décisions finales sans qu'une proposition ne soit envoyée à la liste de diffusion.

Notre intention ici est absolument de ne laisser personne au sec. Nous savons que les PSP répondent à un besoin de sécurité important pour Kubernetes, et le but de ces discussions est de déterminer quelle est la meilleure façon de répondre à ces besoins à l'avenir.