Der Zugangssteuerungscode wird überprüft in: https://github.com/kubernetes/kubernetes/pull/24600

Diese Funktion springt direkt in die Beta, da sie zum ersten Mal in OpenShift verfügbar war.

Es wird standardmäßig in kubernetes/kubernetes#24600 deaktiviert. Danach brauchen wir Änderungen im Admission Controller, um PSPs mit Benutzern zu verknüpfen.

Hinweis auf https://github.com/kubernetes/kubernetes/pull/20573 als Abhängigkeit für den nächsten Schritt auf PSP (Zugriff auf Subjektebene)

Was ist der Stand davon? Ist die Beschreibung im ersten Kommentar aktuell?

Ist die Beschreibung im ersten Kommentar aktuell

nein (Ich habe keine Berechtigung zum Aktualisieren). Ich glaube, dass alle Alpha-Anforderungen erfüllt wurden. Die ursprünglichen Typen, APIs und Tests wurden zusammengeführt. Der Zugangscontroller ist standardmäßig nicht aktiviert.

IMO die verbleibende Arbeit für beta/1.4 ist die Auth-Integration für Berechtigungen, die Aktualisierung für neue Felder, die wir einschränken möchten (seccomp - in Bearbeitung, sysctl) und alle erforderlichen Dokumente/Tutorials.

Und ein e2e-Test.

Am Dienstag, den 12. Juli 2016 um 6:23 Uhr schrieb Paul Weil [email protected] :

Ist die Beschreibung im ersten Kommentar aktuell

nein (Ich habe keine Berechtigung zum Aktualisieren). Ich glaube alle Alpha
Anforderungen erfüllt sind. Die anfänglichen Typen, APIs und Tests waren
zusammengeführt. Der Zugangscontroller ist standardmäßig nicht aktiviert.

IMO die verbleibende Arbeit für Beta/1.4 ist die Auth-Integration für Berechtigungen,
Aktualisierung für neue Felder, die wir einschränken möchten (seccomp - in Bearbeitung,
sysctl) und alle erforderlichen Dokumente/Tutorials.

—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/features/issues/5#issuecomment -232045429,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe/AHuudqFwephlYk0Y1PS77y0xxA5QW0_-ks5qU5U7gaJpZM4IaU8n
.

Wie sieht es mit Interaktionen mit Cloud-Anbietern aus? Es wäre schön, jedem Pod einfach unterschiedliche IAM-Rollen zuzuweisen, damit sie nur auf die Teilmenge von Cloud-Diensten zugreifen können, die sie tatsächlich benötigen. Wäre es im Geltungsbereich oder wird es als SecurityContext-Detail betrachtet?

@therc das sollte über ServiceAccount erfolgen.

@goltermann Mir ist aufgefallen, dass dies mit Alpha gekennzeichnet ist, aber ich glaube, dass es wahrscheinlich das Beta-Tag benötigt, das auf https://github.com/kubernetes/features/issues/5#issuecomment -217939650 basiert

@erictune klingt Beta basierend auf dem @pweil- Kommentar richtig?

@goltermann Ich denke, technisch gesehen wäre dies in 1.3 eine Beta gewesen, es ist nicht neu für 1.4, obwohl die Entwicklung noch nicht abgeschlossen ist.

Ja, Beta stimmt. Ich habe mich geirrt, als ich heute früher Alpha gesagt habe.

super, habs behoben

@pweil- Sind die Dokumente fertig? Bitte aktualisieren Sie die Dokumentation auf https://github.com/kubernetes/kubernetes.github.io , fügen Sie dann PR-Nummern hinzu und aktivieren Sie das Kontrollkästchen für die Dokumentation in der Problembeschreibung

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

edit: https://github.com/kubernetes/kubernetes.github.io/pull/1206 ist die richtige 1.4 PR

cc @kubernetes/feature-reviewers

@pweil- Ich nehme an, diese PR ist aktuell - https://github.com/kubernetes/kubernetes.github.io/pull/1206?

Korrekt

Ausgaben veralten nach 90 Tagen Inaktivität.
Markieren Sie die Ausgabe mit /remove-lifecycle stale als neu.
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Verhindern Sie mit einem /lifecycle frozen -Kommentar, dass Probleme automatisch geschlossen werden.

Wenn Sie dieses Problem jetzt sicher schließen können, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder @fejta .
/Lebenszyklus veraltet

In 1.10 wird daran gearbeitet, PSP in die API-Gruppe ohne Erweiterungen zu verschieben
cc @php-coder

@erictune doc-Updates, bitte? Siehe auch [die 1.10-Funktionsverfolgungstabelle[(https://docs.google.com/spreadsheets/d/17bZrKTk8dOx5nomLrD1-93uBfajK5JS-v1o-nCLJmzE/edit#gid=0)]. lmk, wenn Sie Fragen haben. Wir müssen eine Dokumenten-PR überprüfen und bis zum 9. 3. zusammenführen. Danke!

@php-coder ^

@Bradamant3 @liggitt Welche Dokumentaktualisierungen sind erforderlich?

Für die Änderungen im Zusammenhang mit dem API-Gruppenübergang habe ich Folgendes eingereicht: https://github.com/kubernetes/website/pull/7562 , https://github.com/kubernetes/examples/pull/206 und https:/ /github.com/kubernetes/examples/pull/208

Ich bin nicht der richtige Besitzer für PSP Doc-Updates.

Am Fr, 2. März 2018 um 11:26 Uhr, Vyacheslav Semushin <
[email protected]> schrieb:

@Bradamant3 https://github.com/bradamant3 @liggitt
https://github.com/liggitt Welche Dokumentaktualisierungen sind erforderlich?

Für die Änderungen im Zusammenhang mit der Umstellung der API-Gruppe habe ich Folgendes eingereicht:
kubernetes/website#7562 https://github.com/kubernetes/website/pull/7562 ,
kubernetes/examples#206 https://github.com/kubernetes/examples/pull/206 ,
und kubernetes/examples#208
https://github.com/kubernetes/examples/pull/208

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/features/issues/5#issuecomment-370026485 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AHuudtBCup17Kt91pqJzBRpKWStoXUt-ks5taZzcgaJpZM4IaU8n
.

Das ist alles, was wir brauchen. Ich habe die PR zur Tracking-Tabelle hinzugefügt. Danke!

@php-coder @liggitt @tallclair
Irgendwelche Pläne dafür in 1.11?

Wenn ja, können Sie bitte sicherstellen, dass die Funktion auf dem neuesten Stand ist, mit dem entsprechenden:

• Beschreibung
• Meilenstein
• Zessionar(en)
• Etiketten:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

@php-coder Können Sie mit der Arbeit, die Sie hier leisten , auf den Kommentar von

Gibt es andere Änderungen als die Verschiebung der Richtliniengruppe?

Nein, ich habe nur daran gearbeitet.

Ich hoffe, dass @liggitt die Beschreibung aktualisiert, wenn er Zeit hat (weil ich keine entsprechenden Berechtigungen habe).

Fertig.

@tallclair nur zur Verdeutlichung, wir verfolgen Stable als Ziel für 1.11, richtig?
Ich habe das Etikett aktualisiert, möchte aber nur sichergehen.

Nein, das wird noch Beta sein. Ich bin mir nicht sicher, ob PodSecurityPolicy jemals stabil werden wird (dh durch etwas anderes ersetzt wird), aber andere könnten mir diesbezüglich nicht zustimmen.

Habe es. Danke für das Update, @tallclair!

@justaugustus Ich werde dies aus dem Meilenstein 1.11 entfernen, da es in der aktuellen Version keine wesentlichen Fortschritte geben wird.

Keine Updates geplant für 1.12

@tallclair Ich könnte vielleicht die RunAsGroup PSP-Knöpfe in 1.12 bekommen

Quit. Dies wird jedoch noch in der Beta sein. Im Moment gibt es keine Pläne für PSP, zu GA zu wechseln. Es gibt einige wichtige Usability-Probleme, die angegangen werden müssen, bevor wir damit fortfahren. (siehe https://github.com/kubernetes/kubernetes/issues/60001 und https://github.com/kubernetes/kubernetes/issues/56174)

/Zuweisung aufheben

/zuweisen @tallclair

Hallo
Diese Verbesserung wurde bereits zuvor nachverfolgt, daher würden wir gerne nachsehen, ob es Pläne dafür gibt, die Stufen in Kubernetes 1.13 abzuschließen. Diese Version soll „stabiler“ sein und einen aggressiven Zeitplan haben. Bitte fügen Sie diese Erweiterung nur hinzu, wenn ein hohes Maß an Vertrauen besteht, dass sie die folgenden Fristen einhalten wird:

• Dokumente (offene Platzhalter-PRs): 11/8
• Code-Slush: 11/9
• Code Freeze beginnt: 15.11
• Dokumente vollständig und überprüft: 27.11

Bitte nehmen Sie sich einen Moment Zeit, um die Meilensteine ​​in Ihrem ursprünglichen Beitrag für die zukünftige Nachverfolgung zu aktualisieren, und pingen Sie @kacole2 an, wenn er in das Nachverfolgungsblatt für 1.13 -Verbesserungen aufgenommen werden muss

Danke!

Keine Änderungen in 1.13 geplant.

Ausgaben veralten nach 90 Tagen Inaktivität.
Markieren Sie die Ausgabe mit /remove-lifecycle stale als neu.
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn Sie dieses Problem jetzt sicher schließen können, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus veraltet

/remove-lifecycle veraltet

@tallclair Hallo – ich bin der Leiter der Verbesserung für 1.14 und ich schaue bei diesem Problem vorbei, um zu sehen, welche Arbeiten (falls vorhanden) für die Version 1.14 geplant sind. Das Einfrieren der Erweiterungen ist der 29. Januar und ich möchte daran erinnern, dass alle Erweiterungen ein KEP haben müssen

Nichts geplant für 1.14.

Was sind die Lücken, damit dies GA ist? Mir fallen nur wenige ein, aber ich sehe keine Kriterien in der Beschreibung.

Bevor dies zu GA gehen kann, müssen wir diese Probleme beheben:

1. Fehlerhaftes Autorisierungsmodell – Die PSP-Nutzung wird über RBAC gewährt und kann entweder dem Benutzer oder dem erstellten Pod gewährt werden. Es dem Benutzer zu gewähren, ist der intuitive Ansatz, aber problematisch (siehe Erklärung). Dieser Ansatz hat auch einige Sicherheitsprobleme.
2. Rollout schwierig – Da Pods standardmäßig abgelehnt werden, können wir PSP nicht auf alle Cluster ausrollen, ohne sie zu beschädigen. Ebenso müssen Benutzer, die PSP aktivieren möchten, sicherstellen, dass alle Workloads vollständig abgedeckt sind, bevor sie es aktivieren können, was die Aktivierung erschwert (daher die relativ geringe Nutzung). Da das Feature explizit aktiviert werden muss, haben wir keine ausreichende Testabdeckung (die Feature-Matrix ist zu komplex).
3. Inkonsistente API – Weniger ein grundlegendes Problem, aber die Entwicklung der PSP-API über eine lange Spanne von k8s-Releases hat zu einer Reihe von Inkonsistenzen geführt, die ihre Verwendung erschweren. Insbesondere wird Mutation mit Validierung in einen Topf geworfen, was zu einigen unerwarteten Ergebnissen führen kann, wenn ein Pod Zugriff auf mehrere PSPs hat.

@liggitt und ich haben einige Ideen, wie wir dies angehen können, aber es ist eine offene Frage, ob dies in den Kern von Kubernetes gehört. Ich möchte im nächsten Monat eine Roadmap herausbringen, entweder einen Plan für den Wechsel zu GA oder einen Plan für die Einstellung.

Danke für das Teilen der Informationen!

Da Pods standardmäßig abgelehnt werden, können wir PSP nicht auf alle Cluster ausrollen, ohne sie zu beschädigen.

Ich denke, das ist es nicht wirklich. Wir haben dies getan, indem wir zunächst eine PodSecurityPolicy erstellt haben, die offen genug ist (oder sogar alle offen ist), und diese dann schrittweise verfeinern.

@zhouhaibing089 Ein Kubrenetes-Benutzer kann diese Methode verwenden, die funktioniert, weil er die Richtlinien kontrolliert. Wir können dies jedoch nicht als Kubernetes-Standard einführen, da PodSecurityPolicy nur den Cluster öffnet, was bedeutet, dass es sehr schwierig ist, das systemgesteuerte Allow-All-PSP zu verwalten.

Hallo @liggitt @tallclair , ich bin der Enhancement Lead für 1.15. Wird dieses Feature in 1.15 die Alpha-/Beta-/Stable-Stadien absolvieren? Bitte lassen Sie es mich wissen, damit es ordnungsgemäß nachverfolgt und der Tabelle hinzugefügt werden kann. Der Community-Vorschlag muss für die Aufnahme in 1.15 in ein KEP migriert werden.

Sobald die Kodierung beginnt, listen Sie bitte alle relevanten k/k PRs in dieser Ausgabe auf, damit sie richtig nachverfolgt werden können.

Keine Änderungen geplant für 1.15

@tallclair Würde dieses Land wirklich gerne als GA in 1.16 sehen. Ist das möglich?

@lachie83 Nein, wir sind uns nicht sicher, ob PodSecurityPolicy an GA gehen soll. Es ist nicht klar, dass dies ein Anwendungsfall ist, der vom Kubernetes-Kern gelöst werden sollte, und wir suchen nach Alternativen außerhalb des Kerns. Wenn Sie es ausführlicher diskutieren möchten, ist dies ein gutes Thema für SIG-Auth.

@tallclair Wäre Zeug wie der Gatekeeper von Open Policy Agent ein besserer Weg, um nach unten zu gehen?

Ja genau. Das könnte der führende Anwärter sein, und ich arbeite eng mit diesem Team zusammen, um sicherzustellen, dass es diese Anwendungsfälle abdeckt.

Das einzige, worauf ich gewartet habe, ist ein Tool, das möglicherweise PodSecurityPolicy --> OPA-Rego-Richtlinien übersetzen könnte. Das würde es viel einfacher machen, sie von Ihrem Standpunkt aus abzulehnen.

@tallclair freut sich über die prompte Antwort

@SEJeff stimmte zu. Wir werden PodSecurityPolicy nicht verwerfen, bis es einen eindeutigen Ersatz mit Funktionsparität und Migrationspfad gibt.

Hey @tallclair , du hast eine Roadmap für GA oder einen Plan für die Einstellung erwähnt . Anscheinend tendieren wir zu letzterem.

Haben wir etwas geschrieben, um Leuten zu helfen, die PSPs als Lösung betrachten, um den Kreis zu schließen?

Noch nicht. Ein Teil des Zögerns besteht darin, dass wir nicht sagen wollen, dass wir es zugunsten von etwas anderem ablehnen, bis es einen klaren Ersatz gibt. Obwohl ich von Gatekeeper begeistert bin, hat es noch nicht die Funktionen (oder Stabilität), die wir brauchen, um PSP zu ersetzen. Eine andere Möglichkeit ist, dass wir PSP aus dem Baum verschieben und es als Zulassungs-Webhook zu GA bringen könnten (die beiden Optionen schließen sich nicht gegenseitig aus). Wir haben jedoch noch keine offizielle Roadmap festgelegt.

Wtf

Hallo @tallclair , sieht so aus, als würde hier auch für 1.16 nichts passieren, also werde ich es gleich lassen.

Hallo @tallclair -- 1.17 Enhancement führt hierher -- es sieht so aus, als ob dies für 1.17 so bleibt wie es ist. Wenn sich das ändert, zögern Sie bitte nicht, mir einen Schubs zu geben, und ich kann es dem Verfolgungsbogen hinzufügen 👍

Gab es weitere Diskussionen über einen klaren Weg für die Zukunft von PSP?

Ja genau. Das könnte der führende Anwärter sein, und ich arbeite eng mit diesem Team zusammen, um sicherzustellen, dass es diese Anwendungsfälle abdeckt.

@tallclair – wir haben die meisten PSP-Checks in Kyverno implementiert. Können Sie helfen, einen Blick darauf zu werfen? Würde gerne Ideen und Details besprechen.

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

Das Gatekeeper-Projekt hat sich auch angesehen, wie eine Post-PSP-Welt aussehen würde. Unser erster Ansatz bestand darin, die PSP-Ressource in einzelne Beschränkungen aufzuteilen . Wir haben uns gefragt, was die Community von diesem Ansatz hält. Vielleicht wäre es ein guter Zeitpunkt, sich neu vorzustellen, wie sich diese Richtlinien zusammensetzen? Die Migration sowohl für neue Benutzer als auch für bestehende PSP-Benutzer wird ebenfalls wichtig sein.

cc @maxsmythe @sozercan @tsandall

Ich habe einige Bedenken, die Richtlinien in einzelne Einschränkungen aufzuteilen, nämlich, dass ich viel mehr Einschränkungsobjekte erstellen muss. Wenn ich denke, dass ich diese für verschiedene Workloads klonen oder ändern muss, befürchte ich, dass es sehr komplex wird.

Ich denke, der beste Ansatz wäre ein benutzerzentrierter. Wenn wir echtes Feedback darüber erhalten, wie PSPs verwendet werden, und dann sehen, wie ein ähnliches Setup unter diesen alternativen Plugins aussehen würde, dann kann das helfen, das Design zu formen.

@tallclair Einer der Anwendungsfälle, die wir verfolgen, bezieht sich auf Namespace-basierte Mandantenfähigkeit. Die Absicht besteht darin, Richtlinien zu verwenden, um Einschränkungen durchzusetzen und sicherzustellen, dass Namespaces richtig konfiguriert sind.

Bevor dies zu GA gehen kann, müssen wir diese Probleme beheben:

1. Fehlerhaftes Autorisierungsmodell – Die PSP-Nutzung wird über RBAC gewährt und kann entweder dem Benutzer oder dem erstellten Pod gewährt werden. Es dem Benutzer zu gewähren, ist der intuitive Ansatz, aber problematisch (siehe Erklärung). Dieser Ansatz hat auch einige Sicherheitsprobleme.

@tallclair , ich wundere mich über das oben Gesagte – können Sie erläutern, wie problematisch dieser Ansatz ist und/oder Sicherheitsprobleme hat?

Kann jemand, der informierter ist, bitte diesen Tweet bestätigen:

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

Und wenn das stimmt, was sollten Leute, die heute PSP verwenden, um Linux-Fähigkeiten einzuschränken, in Zukunft tun?

Hallo zusammen,
Dies ist eine sehr interessante Diskussion und wir suchen derzeit nach Lösungen zur sicheren Pod-Erstellung in Kubernetes-Clustern.

Wir haben uns sowohl die OPA Gatekeeper- als auch die PodSecurityPolicies sowie die Bemühungen zur Neuimplementierung von PSP in OPA-Einschränkungen angesehen.
Das grundlegende Problem, das wir bei diesem Vergleich festgestellt haben, ist, dass wir es mit zwei gegensätzlichen Modellen zu tun haben.

• OPA Gatekeeper folgt dem Open-by-Default-Modell, bei dem alles erlaubt ist und der Administrator bestimmte Dinge mit Einschränkungen verbietet.
• PSP folgt dem Closed-by-Default-Modell, bei dem alles verboten ist und der Administrator bestimmte Dinge mit Richtlinien erlaubt.

Aus Sicherheitssicht würde ich argumentieren, dass das PSP-Modell besser ist, wenn auch schwieriger in bestehende Cluster zu integrieren, da alle Workloads damit übereinstimmen müssen.

Wie planen Sie, diese grundlegende Lücke in der Architektur zwischen PSP und dem Constraint Framework zu überbrücken?

/cc @ritazh Ich würde gerne Ihre Meinung dazu hören, da Sie daran gearbeitet haben, die PSP-Funktionalität auf OPA zu portieren.

Die unterschiedlichen Herangehensweisen erschweren die Migration definitiv. Wir untersuchen verschiedene Möglichkeiten, um den Übergang reibungsloser zu gestalten.

In einer perfekten Welt stimme ich zu, dass „Alles standardmäßig verweigern“ der sicherere Ansatz ist. Dies ist jedoch eines der Dinge, die die Verwendung und Einführung von PSP so schwierig machen. In der Praxis halte ich es für praktikabler, Berechtigungen schrittweise herunterzuschrauben, und wie das alte Sprichwort sagt: "Die beste Sicherheit ist die Sicherheit, die Sie verwenden".

Als Nebenbemerkung besprechen wir auch, wie Sie Ausnahmen von Einschränkungen ablehnen/ausschließen/erhalten (z. B. um den kube-system-Namespace zu schützen). Je nachdem, wie dies funktioniert, könnten Sie einen standardmäßigen Deny-Ansatz implementieren, indem Sie alles sperren und dann Ausnahmen gewähren. Ich bin mir nicht sicher, ob das ein Anwendungsfall ist, für den wir entwerfen wollen ...

@tallclair erwartest du irgendwelche Fortschritte in 1.18? Ich bin ein Erweiterungsschatten für die Veröffentlichung und würde gerne wissen, ob wir dies verfolgen sollten.

Keine Änderungen geplant für 1.18

Ausgaben veralten nach 90 Tagen Inaktivität.
Markieren Sie die Ausgabe mit /remove-lifecycle stale als neu.
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn Sie dieses Problem jetzt sicher schließen können, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus veraltet

/remove-lifecycle veraltet

@tallclair Hallo Tim. Irgendwelche Pläne dafür in 1.19?

Keine Pläne für v1.19, obwohl ich hoffe, im Zeitrahmen von v1.20 etwas Bewegung zu sehen.

Bin gerade über Kubernetes Pod Security Policies mit Open Policy Agent gestolpert. @tallclair kannst du uns mitteilen, was uns blockiert und wo Hilfe benötigt wird, gerne auch einen Beitrag leisten.

Können Sie uns mitteilen, was uns blockiert?

Im Grunde müssen wir uns nur für einen Weg nach vorne entscheiden. Momentan denke ich, dass es Einigkeit darüber gibt, dass PSP nicht in seiner jetzigen Form allgemein verfügbar sein sollte, aber wir haben uns noch nicht auf einen Ersatz geeinigt. Optionen, die wir besprochen haben:

1. Kein Ersatz – es wird empfohlen, eine Option eines Drittanbieters mit einem Zulassungs-Webhook auszuwählen. Das kürzlich veröffentlichte Dokument zu den Pod-Sicherheitsstandards versucht, dies reibungsloser zu gestalten, indem es gleichwertige Funktionen fördert.
2. Alternative eingebaute Bedienelemente
   
   
   
   1. @deads2k hat vorgeschlagen, openshifts SecurityContextConstraints hochzuladen
   
   
   2. Ich habe eine minimal konfigurierbare Funktion vorgeschlagen, die nur die oben verlinkten Standardrichtlinien erzwingt (und eine Drittanbieterlösung empfehlen, wenn mehr Konfigurierbarkeit erforderlich ist).
   
   
3. Fix-Pod-Sicherheitsrichtlinie – Obwohl einige der Probleme für das Design so wichtig sind, dass dies nicht abwärtskompatibel sein müsste, könnte es an diesem Punkt genauso gut eine neue Alternative in (2) sein.

Lese ich https://github.com/kubernetes/kubernetes/pull/90603 richtig, dass aufgrund der Veröffentlichung der Pod-Sicherheitsstandards kein Ersatz für PSPs im API-Server geplant ist und jeder Ersatz als externes System implementiert werden muss?

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

Der Ablaufplan für die aktuelle Beta-Version in 1.22 ist unabhängig davon, ob eine In-Tree-Implementierung der Standard-Pod-Sicherheitsprofile bereitgestellt wird oder nicht. Das steht noch nicht fest.

Danke @liggitt hat bestätigt, dass nichts eingestellt wurde. dachte ursprünglich, dass nichts veraltet wäre, bis ein Ersatz verfügbar wäre. Es war nicht klar, ob eine Entscheidung auf die eine oder andere Weise getroffen worden war.

Die Zeitleiste für veraltete Versionen ist nicht spezifisch für PSP und wurde als Teil von https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta hinzugefügt

Wenn ich das richtig lese, ist das, was die Ablehnung vorantreibt, dass keine API länger als 9 Monate in der gleichen Beta-Version sein sollte, also muss PSP befördert oder veraltet werden, und da es keine neuen Betas oder GA von PSP geben wird es muss für die Abwertung auf Kurs gebracht werden, obwohl noch nicht über einen Ersatz entschieden wurde?

Wenn ich das richtig lese, ist das, was die Ablehnung vorantreibt, dass keine API länger als 9 Monate in derselben Beta-Version sein sollte

exakt. Alle zukünftigen Beta-Versionen aller integrierten APIs werden bei ihrer Einführung mit einem vorgefertigten Verfalls- und Entfernungsziel geliefert

Hallo @tallclair

Verbesserungen führen hier. Irgendwelche Pläne dafür in 1.20?

Danke,
Kirsten

Keine Pläne für v1.20.

Diese Situation ist äußerst frustrierend für diejenigen von uns, die Hochsicherheitscluster betreiben müssen. Unsere Optionen sind:

1. Sitzen und warten, bis PSPs veraltet sind.
2. Lagern Sie die Workload-Runtime-Sicherheitsdurchsetzung an einen Anbieter (Styra) aus, da OPA nicht dokumentiert, wie ein vollständig restriktiver PSP-Ersatz mit Rego ausgeführt wird.

Mein Unternehmen hat also vollständig gesperrte PSPs implementiert. Sie sind nicht einfach zu implementieren, und das Debuggen ist eine lästige Pflicht, aber sie sind hochfunktional und funktionieren tatsächlich. Wir haben sogar einen Blogbeitrag veröffentlicht, in dem detailliert beschrieben wird, wie sie auf diese Weise verwendet werden können und wie mit Ausnahmen umgegangen wird, wenn sie auftreten.

Meiner Meinung nach sollte die PSP-Beta so wie sie ist in den Mainline-Kubernetes-Core eingebunden werden. Meine Gründe sind:

1. Während PSPs Fehler haben, funktionieren sie und haben für 10 Versionen funktioniert.
2. Kubernetes als Projekt sollte sich um die Workload-Laufzeitsicherheit kümmern. Containerfluchten sind viel zu einfach. PSPs sind eines der wenigen Tools, die Angreifern dies erschweren.
3. Perfekt ist der Feind von Done. Führen Sie die PSPs so zusammen, wie sie sind, und verschieben Sie die „bessere“ Implementierung nach policy/v2.
4. Schließlich, und das ist am wichtigsten, ermöglicht es OSS-Entwicklern, Cluster mit höherer Sicherheit zu betreiben, nicht nur Unternehmen, die sich Anbieter wie Styra leisten können.

@zapman449 kannst du klarstellen, was du mit einem "vollständig restriktiven PSP-Ersatz" meinst?

Hoffentlich macht es die Gatekeeper-PSP-Bibliothek einfacher, Regeln durchzusetzen, die denen ähnlich sind, die von PSP verwendet werden. Ich bin auf jeden Fall an allen Funktionslücken interessiert, die Sie sehen.

@zapman449 hättest du zufällig einen Link zu diesem Blogpost?

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

@maxsmythe Ich habe noch nicht verstanden, was Gatekeeper PSP macht, werde es überprüfen.

Was ich aber meine ist:

1. Vollständige Kontrolle über Prozessfunktionen wie NET_BIND_SERVICE, SYS_ADMIN usw
2. Beschränken Sie UID/GID/FSGroups auf Werte ungleich Null
3. Explizite Auflistung von Hostpfaden, die gemountet werden können
4. Explizite Auflistung der Arten von zulässigen Volume-Mounts
5. Privilegiert blockieren, Privilegienausweitung blockieren
6. Blockieren Sie den Zugriff auf Primitive für die Kommunikation zwischen Prozessen auf Hostebene
7. Blockieren Sie den Zugriff auf das Hostnetzwerk
8. beschränken, welche Host-Ports erlaubt sind
9. ReadOnlyRootFilesystem erzwingen
10. Verbindungspunkt für SELinux

Diese werden heute mit PSPs bereitgestellt.

Wenn wir nach einer Wunschliste fragen, würde ich mich über Folgendes freuen:

1. Intelligente Standardeinstellungen für SysCalls aus Containern. Es gibt einen kleinen Prozentsatz der gesamten Linux-Systemaufrufliste, den die meisten Container benötigen. Lassen Sie mich die meisten Container auf diese Liste beschränken und mir dann erlauben, entweder bestimmte Aufrufe für bestimmte Pods, die bestimmten Dienstkonten gehören, explizit zuzulassen oder bestimmten Dienstkonten Freibrief zu erteilen.
2. Lass mich noch ein bisschen träumen, und mir fällt etwas ein. ;-)

@zapman449 – Falls Sie es noch nicht gesehen haben, wir haben die Zukunft von PSPs im letzten Sig-Auth-Meeting diskutiert (https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#heading=h.hsgtsqg83z5u ). Wir werden die Diskussion in der Sitzung am 9. Dezember fortsetzen, wenn Sie es schaffen, aber wir werden auch keine endgültigen Entscheidungen treffen, ohne dass ein Vorschlag an die Mailingliste gesendet wird.

Unsere Absicht hier ist absolut niemanden auf dem Trockenen zu lassen. Wir wissen, dass PSPs einen wichtigen Sicherheitsbedarf für Kubernetes ansprechen, und der Zweck dieser Diskussionen besteht darin, herauszufinden, wie diese Anforderungen in Zukunft am besten erfüllt werden können.