@derekwaynecarr @sttts @erictune hat dafür kein Problem gesehen, aber es ist bereits in der Alpha. Erstellen Sie dies als Erinnerung, um es in die Beta- und Stable-Phase zu bringen.

@sttts könnten Sie die entsprechenden Links zu Dokumenten und PRs bereitstellen? Ich denke, Sie sind diesem Code am nächsten.

@pweil- @sttts -

@pweil- @derekwaynecarr Bitte bestätigen Sie, dass diese Funktion mit dem 1.6-Meilenstein eingestellt werden muss.

@idvoretskyi Wir

@sttts danke.

Sieht so aus, als ob das noch Alpha ist:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/seccomp.md
https://github.com/kubernetes/kubernetes/blob/master/pkg/api/annotation_key_constants.go#L35

Und ich konnte auf kubernetes.io/docs keine Dokumentation finden.

@pweil- irgendwelche Updates für 1.8? Ist diese Funktion noch auf dem richtigen Weg für die Veröffentlichung?

@idvoretskyi das war keine Priorität für 1.8. @php-coder kannst du dazu eine Karte für unsere PM-Planung hinzufügen? Wir müssen aufhören, dies durch die Ritzen fallen zu lassen und es auf Beta und GA verschieben.

@pweil- wenn dieses Feature nicht für 1.8 geplant ist - bitte aktualisiere den Meilenstein mit dem "nächsten Meilenstein" oder "1.9"

Ich würde gerne sehen, dass dies in die Beta kommt. Prioritäten (oder Anforderungen) dafür sind:

1. Anmerkungen (Pod & PodSecurityPolicy) müssen in Felder im Container SecurityContext verschoben werden (siehe https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#alpha-field- in-existierende-API-Version)
2. Entscheiden Sie sich für das OCI-Spezifikation und definieren Sie ein Kubernetes-Standardprofil (können wir das von Docker wiederverwenden?) https://github.com/kubernetes/kubernetes/issues/39128
   A. Finden Sie heraus, wie das Kubernetes-Profil über CRI an die Container-Laufzeit geliefert wird (/cc @yujuhong @Random-Liu )
   B. docker/default sollte weiterhin erlaubt sein, wenn die Laufzeit Docker ist (aus Gründen der Abwärtskompatibilität)
3. Das Kubernetes-Standardprofil sollte der neue Standard sein. Aus Gründen der Abwärtskompatibilität MUSS dies ein optionales Verhalten sein (dh Flag-gesteuert). https://github.com/kubernetes/kubernetes/issues/39845

Ist jemand daran interessiert, diese Arbeit für den Meilenstein 1.9 (oder 1.10) voranzutreiben? @jessfraz @kubernetes/sig-auth-feature-requests und @kubernetes/sig-node-feature-requests Ich schaue dich an :wink:

Auch relevant: https://github.com/kubernetes/community/pull/660 (Müssen wir die Entscheidungen in dieser PR regeln, bevor wir fortfahren?)

/cc @destijl

Wenn jemand Zeit hat und es tun möchte, ist er herzlich willkommen und ich
hilft bei Fragen

Am 22. September 2017, 20:54 Uhr, "Tim Allclair (St. Clair)" [email protected]
schrieb:

/cc @destijl https://github.com/destijl

—
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/135#issuecomment-331593048 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABYNbDldlrwbOP75Y2AKM-bUFLnwrq0eks5slFbcgaJpZM4KgBy_
.

ok, ich werde den Vorschlag aktualisieren und morgen damit beginnen, wenn es sonst niemand tut ;)

Die Probleme veralten nach 90 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle stale .
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Verhindern Sie das automatische Schließen von Problemen mit einem /lifecycle frozen Kommentar.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

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

Hey @jessfraz , ich bin

Abgestandene Ausgaben verrotten nach 30 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle rotten .
Faule Probleme werden nach weiteren 30 Tagen Inaktivität geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus faul
/Remove-Lifecycle-Stale

Faule Probleme werden nach 30 Tagen Inaktivität geschlossen.
Öffnen Sie das Problem erneut mit /reopen .
Markieren Sie das Problem mit /remove-lifecycle rotten .

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

/wieder öffnen
/Lebenszyklus eingefroren
/remove-lifecycle faul

@php-coder: Sie können ein Problem/eine PR nicht erneut öffnen, es sei denn, Sie haben es verfasst oder es wurde Ihnen zugewiesen.

/wieder öffnen
/Lebenszyklus eingefroren

Am Mo, 26. März 2018 um 7:07 Uhr, k8s-ci-robot [email protected]
schrieb:

@php-coder https://github.com/php-coder : Sie können ein Problem/PR nicht erneut öffnen
es sei denn, Sie haben es erstellt oder Sie sind ihm zugewiesen.

Als Antwort darauf
https://github.com/kubernetes/features/issues/135#issuecomment-376129291
:

/wieder öffnen
/Lebenszyklus eingefroren
/remove-lifecycle faul

Anweisungen zur Interaktion mit mir über PR-Kommentare finden Sie hier
https://git.k8s.io/community/contributors/devel/pull-requests.md . Wenn
Sie haben Fragen oder Anregungen zu meinem Verhalten, bitte melden Sie sich an
Problem gegen die Kubernetes/Test-Infra
https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:
Repository.

—
Sie erhalten dies, weil Sie in einem Team sind, das erwähnt wurde.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/features/issues/135#issuecomment-376129294 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABG_p9EwKebniej_GySRKSvzrCMITOA1ks5tiMvrgaJpZM4KgBy_
.

@smarterclayton : Sie können ein Problem/eine PR nicht erneut öffnen, es sei denn, Sie haben es verfasst oder es wurde Ihnen zugewiesen.

/wieder öffnen

@idvoretskyi : Sie können ein Problem/eine PR nicht erneut öffnen, es sei denn, Sie haben es verfasst oder Sie sind ihm zugewiesen.

Ihor 1, bot 0

@pweil- @php-coder @jessfraz
Gibt es Pläne dafür in 1.11?

Wenn dies der Fall ist, können Sie bitte sicherstellen, dass die Funktion mit den entsprechenden Informationen auf dem neuesten Stand ist:

• Beschreibung
• Meilenstein
• Bevollmächtigte(n)
• Etiketten:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

@wangzhen127 arbeitet daran, kann aber nicht zugewiesen werden, da er noch kein Mitglied ist.

https://github.com/kubernetes/kubernetes/pull/62662
https://github.com/kubernetes/kubernetes/pull/62671

Danke für das Update, Tim!
/remove-lifecycle eingefroren

@pweil- @tallclair - Wir machen noch einen Durchlauf der Tabelle 1.11 Features Tracking .
Würde es Ihnen etwas ausmachen, unvollständige/leere Felder für die Werbebuchung dieser Funktion auszufüllen?

@pweil- @tallclair -- diese Funktion wurde aus dem 1.11-Meilenstein entfernt, da es keine Aktualisierungen bezüglich des Fortschritts oder der Dokumente gab.

cc: @jberkus

@pweil- @tallclair @kubernetes/sig-auth-feature-requests @kubernetes/sig-node-feature-requests --

Diese Funktion wurde aus dem vorherigen Meilenstein entfernt, daher würden wir gerne prüfen, ob dies in Kubernetes 1.12 geplant ist.

Wenn dies der Fall ist, stellen Sie bitte sicher, dass dieses Problem mit ALLEN der folgenden Informationen aktuell ist:

• Einzeilige Funktionsbeschreibung (kann als Versionshinweis verwendet werden):
• Hauptansprechpartner (Beauftragter):
• Verantwortliche SIGs:
• Link zum Designvorschlag (Community-Repository):
• Link zu e2e- und/oder Unit-Tests:
• Rezensenten - (für LGTM) empfehlen, dass 2+ Rezensenten (mindestens einer aus der Datei OWNERS des Codebereichs) der Überprüfung zugestimmt haben. Rezensenten von mehreren Unternehmen bevorzugt:
• Genehmiger (wahrscheinlich von SIG/Gebiet, zu dem das Feature gehört):
• Funktionsziel (welches Ziel entspricht welchem ​​Meilenstein):
  
  
  
  • Alpha-Release-Ziel (xy)
  
  
  • Beta-Release-Ziel (xy)
  
  
  • Stabiles Freigabeziel (xy)
  
  

Bitte beachten Sie, dass die Funktionssperre am 31. Juli endet. Danach erfordern unvollständige Funktionsprobleme eine Ausnahmeanfrage , um in den Meilenstein aufgenommen zu werden.

Bitte beachten Sie außerdem die folgenden relevanten Fristen:

• Docs-Deadline (offene Platzhalter-PRs): 21.8
• Testfall einfrieren: 8/28

Bitte stellen Sie sicher, dass alle PRs für Funktionen auch relevante Versionshinweise enthalten.

Glücklicher Versand!

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

Keine Änderungen geplant für 1.12

Danke für das Update, @tallclair!

Ist jemand daran interessiert, diese Arbeit für den Meilenstein 1.9 (oder 1.10) voranzutreiben? @jessfraz @kubernetes/sig-auth-feature-requests und @kubernetes/sig-node-feature-requests Ich schaue dich an zwinker

@tallclair Ich kann versuchen, das jetzt abzuholen, wenn es noch wünschenswert ist

@stlaz : Wiederholung der Erwähnungen, um eine Benachrichtigung auszulösen:
@kubernetes/sig-auth-feature-requests, @kubernetes/sig-node-feature-requests

@stlaz , diese Funktion ist immer noch erwünscht. Ich habe einige Zeit damit verbracht, Addons als erste Schritte von #39845 seccomp-Profile

@wangzhen127 Danke, ich habe versucht, die Dinge, die getan wurden, und die Probleme im Zusammenhang mit dieser Funktion https://github.com/kubernetes/features/issues/135#issuecomment -331592961 immer noch gültig ist und genau die Arbeit zusammenfasst, die jetzt erledigt werden muss.

Mir ist auch aufgefallen, dass Sie versucht haben, dafür ein FeatureGate hinzuzufügen, aber die PR geschlossen haben, warum war das so?

PS: Sorry für die späte Antwort, ich war kurz weg.

Es scheint, dass der Kommentar #135 (Kommentar) immer noch gültig ist und genau die Arbeit zusammenfasst, die jetzt erledigt werden muss.

Das ist richtig. Eine weitere Sache, die ich hinzufügen möchte, ist ein "Beschwerdemodus". Benutzer haben also die Wahl, Warnungen (in Protokollen) zu erhalten, verbotene Systemaufrufe zu verwenden, anstatt zu töten. Die Protokollierung von seccomp-Aktionen ist mit Linux-Kernel 4.14+ ( seccomp doc ) verfügbar. Es ist möglich, dass noch ältere Kernel-Versionen verwendet werden. Also müssen wir damit umgehen. Dies muss auch der OCI-Spezifikation hinzugefügt werden.

Mir ist auch aufgefallen, dass Sie versucht haben, dafür ein FeatureGate hinzuzufügen, aber die PR geschlossen haben, warum war das so?

Der Zweck dieses Feature-Gates bestand darin, das Standardprofil von seccomp von unbeschränkt auf "Laufzeit/Standard" zu ändern. Ich hatte viele Bedenken bezüglich der Abwärtskompatibilität, so dass dies unwahrscheinlich schien. Wir haben derzeit keinen Plan, die Sicherheitsstandards im Allgemeinen zu ändern, da diese nicht funktionieren. Der beste Ansatz, den ich derzeit denke, ist, seccomp auf Stable zu bringen, und es muss immer noch eine Opt-In-Funktion sein, anstatt eine Opt-Out-Funktion.

Die Protokollierung von seccomp-Aktionen ist mit Linux-Kernel 4.14+ ( seccomp doc ) verfügbar.

Ich denke, da wir im zweiten Schritt ein Kubernetes-spezifisches Standard-seccomp-Format definieren, könnten wir auch eines haben, das stattdessen protokolliert. Gibt es genug Wert dafür? Könnte es für Leute verwendet werden, von "unconfined" zu "kube/default" zu wechseln, wenn letzteres zu sehr fehlschlägt? Würde es ihnen etwas ausmachen, zu Switch-Back zu wechseln?
Es gibt LTS-Distributionen, die 4.13-Linux-Kernel verwenden (Debian - 8,9; RHEL - 6, 7; Ubuntu LTS - 14.04, 16.04), daher ist die Kernel-Kompatibilität definitiv zu beachten.

Ich hatte viele Bedenken bezüglich der Abwärtskompatibilität, so dass dies unwahrscheinlich schien.

Diesen Wechsel mussten auch die Container-Laufzeiten in der Vergangenheit durchmachen, als sie seccomp zum ersten Mal aktivierten. Im Moment wird zumindest Docker mit einem Standardverhalten ausgeliefert, das weniger zulässt als "unconfined", das möglicherweise jemanden hätte kaputt machen können. Ich glaube nicht, dass wir etwas falsch machen, wenn wir nur dem Verhalten der zugrunde liegenden Komponenten folgen (die auch die Möglichkeit bieten, dieses Verhalten auszuschalten).

Gibt es genug Wert dafür?

Dies kann besprochen werden. Mein ursprünglicher Gedanke war, die Standardeinstellung von unbeschränkt auf Protokollierung zu ändern. Wir haben also kein Problem mit der Abwärtskompatibilität. Und wenn wir irgendwie Daten sammeln und zeigen können, dass wir in X% der Fälle nichts protokolliert sehen, was bedeutet, dass das Standardprofil nichts kaputt macht. Dann können wir vorschlagen, die Protokollierung auf kill zu ändern. Das Sammeln von Daten ist knifflig und kann viel Arbeit bedeuten. Selbst wenn wir diesen Weg nicht gehen, denke ich, dass ein Logging-Profil für Leute von Vorteil wäre, die Seccomp ausprobieren möchten, aber noch nicht sicher sind.

Diesen Wechsel mussten auch die Container-Laufzeiten in der Vergangenheit durchmachen, als sie seccomp zum ersten Mal aktivierten. Im Moment wird zumindest Docker mit einem Standardverhalten ausgeliefert, das weniger zulässt als "unconfined", das möglicherweise jemanden hätte kaputt machen können. Ich glaube nicht, dass wir etwas falsch machen, wenn wir nur dem Verhalten der zugrunde liegenden Komponenten folgen (die auch die Möglichkeit bieten, dieses Verhalten auszuschalten).

Wenn Docker den Standardwert geändert hat, setzt Kubernetes diesen Wert explizit auf nicht beschränkt zurück. Ich habe mich zuvor offline an die Leute von sig-architecture gewandt, und sie sind sehr besorgt über das Problem mit der Abwärtskompatibilität.

Und wenn wir irgendwie Daten sammeln und zeigen können, dass wir in X% der Fälle nichts protokolliert sehen, was bedeutet, dass das Standardprofil nichts kaputt macht.

Ich mag diese Idee. Der schwierige Teil ist natürlich, die Daten zu bekommen, ich habe keine Ahnung, wie ich das hinbekomme. Außerdem müssten wir diese Änderung zuerst an der OCI-Spezifikation vorschlagen und sie dann wahrscheinlich für mindestens eine Container-Laufzeit implementieren, oder? Wäre das im Beta-Teil des Lebenszyklus in Ordnung?

Wenn Docker den Standardwert geändert hat, setzt Kubernetes diesen Wert explizit auf nicht beschränkt zurück. Ich habe mich zuvor offline an die Leute von sig-architecture gewandt, und sie sind sehr besorgt über das Problem mit der Abwärtskompatibilität.

Ich verstehe. Vielleicht könnten wir in der Tat einfach das "unbegrenzte" Profil als Standardprofil verwenden (möglicherweise später durch etwas wie kube/logging ersetzen). Es scheint, dass dies dann eher von PSPs in einer Deny-Rule-Manier gesteuert werden könnte, wobei wir davon ausgehen, dass standardmäßig alles erlaubt ist und wir die Privilegien nur weiter reduzieren. Eine Flag-Kontrolle darüber kann jedoch in Fällen nützlich sein, in denen PSPs ausgeschaltet sind, so dass man auch hineingehen sollte, aber diese beiden Mechanismen gleichzeitig zu verwenden, wäre wahrscheinlich etwas chaotisch.

Ich denke, es ist eine etwas andere Richtung als ursprünglich angenommen - es widerspricht der Arbeit in https://github.com/kubernetes/kubernetes/issues/39845 , aber wenn wir uns auf das oben Gesagte einigen, sollten wir an die seccomp-Profile denken Wir werden schließlich versenden. Bisher sehe ich runtime/default , kube/default , kube/logging , zusammen mit der Option, das Profil auf unconfined . Der Rest ist natürlich die Möglichkeit, localhost/.* Profile zu haben, die bereits von der aktuellen Implementierung bereitgestellt wird.

Wäre das im Beta-Teil des Lebenszyklus in Ordnung?

Klingt gut für mich. Obwohl ich denke, dass es hilft, den OCI-Spezifikationsvorschlag frühzeitig zu starten.

Gehe mit "unconfined" als Standard für jetzt klingt gut für mich. Für kubernetes/kubernetes#39845 habe ich Anmerkungen zu Addons hinzugefügt. Und ich glaube nicht, dass wir weiter gehen können.

Bisher sehe ich runtime/default, kube/default, kube/logging, zusammen mit der Option, das Profil auf nicht beschränkt zu setzen. Der Rest ist natürlich die Möglichkeit, localhost/.*-Profile zu haben, die bereits von der aktuellen Implementierung bereitgestellt wird.

Funktioniert bei mir. Für kube/default können wir einfach mit docker/default .

Die Protokollierung von seccomp-Aktionen ist mit Linux-Kernel 4.14+ (seccomp doc) verfügbar.

Mein Verständnis ist, dass dies die Aktion mit der PID protokolliert - nicht unbedingt containerbezogene Informationen. Also muss entweder auditd oder ein anderer Daemon auf dem Host eine Suche/Zuordnung durchführen, damit das Protokoll wirklich nützlich ist ...

Und wenn wir irgendwie Daten sammeln und zeigen können, dass wir in X% der Fälle nichts protokolliert sehen, was bedeutet, dass das Standardprofil nichts kaputt macht. Dann können wir vorschlagen, die Protokollierung auf kill zu ändern. Das Sammeln von Daten ist knifflig und kann viel Arbeit bedeuten.

Hat @jessfraz das nicht bereits beim Starten des Docker-Standardprofils für Docker getan? Wenn das Signal nicht stark genug ist, wird es sehr schwierig sein, ein stärkeres zu sammeln...

@tallclair du hast recht, ich habe mich in all den Kommentaren zu den Problemen irgendwie verloren. Als Referenz hier der Kommentar, der besagt, dass Dockerfiles überprüft wurden: https://github.com/kubernetes/community/pull/660#issuecomment -303860107. Ich denke, wir könnten sicher sein, dass wir doch einen "tötenden" Standard haben.

Hi
Diese Verbesserung wurde bereits nachverfolgt, daher möchten wir gerne prüfen, ob es Pläne für diese Erweiterung der Phasen in Kubernetes 1.13 gibt. Diese Version soll "stabiler" sein und einen aggressiven Zeitplan haben. Bitte nehmen Sie diese Erweiterung nur auf, wenn ein hohes Maß an Vertrauen besteht, dass die folgenden Fristen eingehalten werden:

• Docs (offene Platzhalter-PRs): 11/8
• Code-Slush: 11/9
• Code-Einfrieren beginnt: 11/15
• Vollständige und überprüfte Dokumente: 27.11

Bitte nehmen Sie sich einen Moment Zeit, um die Meilensteine ​​in Ihrem ursprünglichen Beitrag für die zukünftige Verfolgung zu aktualisieren und pingen Sie Tracking-Blatt für 1.13 Verbesserungen aufgenommen werden müssen

Vielen Dank!

Die Probleme veralten nach 90 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle stale .
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

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

Erweiterungsprobleme, die in kubernetes/enhancements geöffnet wurden, sollten niemals als eingefroren markiert werden.
Besitzer von Verbesserungen können sicherstellen, dass die Verbesserungen aktuell bleiben, indem sie ihren Status über die Release-Zyklen hinweg konsistent aktualisieren.

/remove-lifecycle eingefroren

Abgestandene Ausgaben verrotten nach 30 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle rotten .
Faule Probleme werden nach weiteren 30 Tagen Inaktivität geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

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

/remove-lifecycle faul

Hallo @stlaz @pweil- , ich bin der Enhancement Lead für 1.15. Wird diese Funktion in 1.15 die Alpha-/Beta-/Stable-Phasen abschließen? Bitte lassen Sie es mich wissen, damit es richtig verfolgt und der Tabelle hinzugefügt werden kann. Dies erfordert auch, dass ein KEP in 1,15 aufgenommen wird

Sobald die Codierung beginnt, listen Sie bitte alle relevanten k/k-PRs in dieser Ausgabe auf, damit sie ordnungsgemäß nachverfolgt werden können.

keine Änderungen geplant für 1.15

Hallo @tallclair @pweil- @stlaz , ich bin der 1.16 Enhancement Lead/Shadow. Wird diese Funktion in 1.16 die Alpha-/Beta-/Stable-Phasen abschließen? Bitte lassen Sie es mich wissen, damit es der 1.16 Tracking-Tabelle hinzugefügt werden kann. Wenn dies nicht der Fall ist, werde ich es aus dem Meilenstein entfernen und das nachverfolgte Label ändern.

Wenn die Codierung beginnt oder bereits erfolgt ist, listen Sie bitte alle relevanten k/k-PRs in dieser Ausgabe auf, damit sie ordnungsgemäß nachverfolgt werden können.

Zur Erinnerung: Jede Verbesserung erfordert eine KEP in einem implementierbaren Zustand mit Abschlusskriterien, die die Anforderungen jeder Alpha-/Beta-/Stable-Phase erklären.

Meilensteintermine sind Enhancement Freeze 30.07. und Code Freeze 29.08.

Dankeschön.

Ich habe die Anfänge eines Plans, es auf GA zu bringen, aber es könnte ein langer Weg sein, um in 1.16 dazu zu kommen. Ich werde versuchen, einen Vorschlag durch das Einfrieren von Verbesserungen herauszubekommen.

Hallo @tallclair @pweil- , 1.17 Enhancement Shadow hier! 🙂

Ich wollte wissen, ob diese Erweiterung in 1.17 auf Alpha/Beta/Stable abgestuft wird.
Bitte lassen Sie es mich wissen, damit diese Erweiterung dem Tracking-Sheet 1.17 hinzugefügt werden kann.

Dankeschön!

🔔Freundliche Erinnerung

• Der aktuelle Veröffentlichungsplan ist
  
  
  
  • Montag, 23. September - Der Release-Zyklus beginnt
  
  
  • Dienstag, 15. Oktober, EOD PST – Einfrieren der Verbesserungen
  
  
  • Donnerstag, 14. November EOD PST - Code Freeze
  
  
  • Dienstag, 19. November – Dokumente müssen ausgefüllt und überprüft werden
  
  
  • Montag, 9. Dezember – Kubernetes 1.17.0 veröffentlicht
  
  

• Ein Kubernetes Enhancement Proposal (KEP) muss die folgenden Kriterien erfüllen, bevor Enhancement Freeze in die Version aufgenommen werden kann

  • PR wird zusammengeführt in
  • In einem implementable Zustand
  • Testplan und Abschlusskriterien einschließen

• Alle relevanten k/k PRs sollten in dieser Ausgabe aufgeführt werden

Ja, ich plane, dies in v1.17 zu stabil zu machen - KEP hier: https://github.com/kubernetes/enhancements/pull/1148

Hey @tallclair , ich werde diese Verbesserung dem zu verfolgenden Tracking-Sheet hinzufügen

Bitte beachten Sie die obige Nachricht für freundliche Erinnerungen und beachten Sie, dass sich KEP in einem vorläufigen Zustand befindet. KEP muss sich in einem implementierbaren Zustand befinden, um zu Version 1.17 hinzugefügt zu werden.

/Meilenstein v1.17
/bühnenstall

Hey @tallclair Könnten Sie bitte Links zu den Tests in testgrid posten und alle Tests verfolgen, die für diese Verbesserung hinzugefügt wurden?

Dankeschön!

Wird besorgt. Es gibt bereits eine Reihe von seccomp-Tests, aber ich kann sie auf keinem Dashboard-Tab finden (gibt es überhaupt eine Möglichkeit, in allen Testgrids nach einem bestimmten Test zu suchen?)
https://github.com/kubernetes/kubernetes/blob/0956acbed17fb71e76e3fbde89f2da9f8ec8b603/test/e2e/node/security_context.go#L147 -L177

@tallclair es gibt keine gute Möglichkeit, in allen Testgrids zu suchen =/

Meine beste Vermutung (zumindest für die 4, auf die Sie verwiesen haben), ist, dass sie nicht tatsächlich enthalten sind. 😬

Sie sehen so aus, als ob sie ein Teil des node-kubelet-features-Dashboards sein sollten , aber die Jobkonfiguration für test_args :

--test_args=--nodes=8 --focus="\[NodeFeature:.+\]" --skip="\[Flaky\]|\[Serial\]"

Die Ginkgo-Tests selbst sind mit [Feature:Seccomp] und das Fokus-Flag würde nicht übereinstimmen.

Ich denke, wir sollten das Feature-Tag einfach entfernen, sobald dies in GA verschoben wird. Ich denke, seccomp ist unter Linux Standard, daher sollte das Tag [LinuxOnly] ausreichen.

Für das allgemeine Problem, dass Tests nicht ausgeführt werden, habe ich https://github.com/kubernetes/test-infra/issues/14647 eingereicht

Hey @tallclair , wir sind nur noch 5 Tage bis zum Enhancements Freeze (Dienstag, 15. Oktober, EOD PST) . Eine weitere freundliche Erinnerung daran, dass KEP eingebunden werden muss und sich in einem implementierbaren Zustand befinden muss, um dies in der Version 1.17 graduieren zu können. Sieht so aus, als ob das KEP noch geöffnet ist und sich in einem provisorischen Zustand befindet.

Hey @tallclair , leider ist die Frist für das Einfrieren der Erweiterung 1.17 abgelaufen und es sieht so aus, als ob das KEP noch offen ist. Ich werde diese Verbesserung aus dem 1.17-Meilenstein entfernen.

Bitte beachten Sie, dass Sie eine Erweiterungsausnahme einreichen können, wenn Sie diese für 1,17 . benötigen

/Meilenstein klar

Ja, hat den Schnitt nicht geschafft. In der Hoffnung, es zu bekommen
/Meilenstein v1.18

Das klingt gut! Ich werde dies im Verbesserungs-Tracking-Sheet als auf v1.18 verschoben markieren.

Hey 👋, können wir etwas tun, um das hier voranzubringen. Ich würde mich freuen, sowohl hier als auch für die AppArmor-Ausgabe einen Beitrag zu leisten.

Hey @tallclair

1.18 Erweiterungsteam checkt ein! Planen Sie einen Abschluss in 1.18 als stabil? Es sieht so aus, als ob das KEP noch geöffnet ist.

Der Veröffentlichungsplan sieht wie folgt aus:

Verbessern Freeze: 28. Januar
Code einfrieren: 5. März
Dokumente bereit: 16. März
v1.18 Veröffentlichung: 24. März

Zur Erinnerung: Der KEP muss zusammengeführt werden, wobei der Status auf implementable .

Vielen Dank!

@saschagrunert danke für das Angebot! Ich muss einen weiteren Pass beim KEP machen, um die API-Überprüfung zu verfolgen, die ich mit @liggitt hatte. Sobald das KEP genehmigt ist, würde ich mich über Ihre Hilfe bei der Implementierung freuen.

Ich denke, die größte offene Frage zum KEP ist derzeit, wie der Profiltyp localhost zu handhaben ist. Da wir die Funktion ablehnen möchten (idealerweise zu Gunsten von so etwas wie https://github.com/kubernetes/enhancements/pull/1269, /cc

Hey @tallclair , gibt es ein Update, ob es in 1.18 kommt oder nicht? Es ist derzeit im Meilenstein markiert, aber Sie haben nicht bestätigt, ob wir dies verfolgen sollen oder nicht.

Vielen Dank!

v1.18 scheint dafür unwahrscheinlich. Ich denke, wir können uns anstoßen
/Meilenstein v1.19

Super , danke für das Update

Hallo @tallclair -- 1.19 Erweiterungen Führen Sie hier an, planen Sie, diese Erweiterung in dieser Version auf stable ?

Keine Pläne für einen Abschluss in v1.19. Ich habe eine offene KEP, werde aber dieses Quartal nicht daran arbeiten. @pjbgf kann es in v1.20 aufnehmen

@tallclair -- Vielen Dank für die Updates. :leicht_smiling_face:

/Meilenstein v1.20

Diesbezüglich gab es eine geringfügige Änderung der Pläne - wie beim gestrigen Sign-Node-Treffen vereinbart. Dies ist nun geplant für:

/Meilenstein v1.19

@pjbgf : Sie müssen Mitglied des kubernetes/milestone-maintainers GitHub-Teams sein, um den Meilenstein zu setzen. Wenn Sie der Meinung sind, dass Sie den /milestone-Befehl ausgeben können sollten, wenden Sie sich bitte an Ihren und lassen Sie sich von ihm als zusätzlichen Delegierten für diese Verantwortung vorschlagen.

@palnabarun Macht es Ihnen etwas aus, dieses Problem auf Meilenstein v1.19 zu setzen?

/pjbgf zuweisen

/Meilenstein v1.19

Danke @pjbgf @tallclair für das Update. Ich habe das Tracking-Sheet gemäß Ihren Plänen aktualisiert.

Können Sie mir bitte mitteilen, welche Abschlussphase Sie anstreben und einen Link zum KEP?

Dankeschön! Schätzen Sie alle Bemühungen. :leicht_smiling_face:

Der aktuelle Veröffentlichungsplan ist:

• Montag, 13. April: Woche 1 - Release-Zyklus beginnt
• Dienstag, 19. Mai: Woche 6 – Einfrieren der Verbesserungen
• Donnerstag, 25. Juni: Woche 11 - Code Freeze
• Donnerstag, 9. Juli: Woche 14 – Dokumente müssen ausgefüllt und überprüft werden
• Dienstag, 4. August: Woche 17 - Kubernetes v1.19.0 veröffentlicht

Ausrichtung auf GA

KEP: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md
Die KEP hat noch ungelöste Abschnitte mit Folge-PR: https://github.com/kubernetes/enhancements/pull/1747

Hallo @tallclair , danke für das Update. :+1:

Ich habe das Tracking-Sheet entsprechend aktualisiert.

PS: Ich habe die Problembeschreibung mit Links zum KEP und dem neuesten KEP-Update-PR aktualisiert.

danke @palnabarun für das Update. :+1:

Hallo @tallclair 👋 1.19 docs shadow hier! Erfordert diese für 1.19 geplante Erweiterungsarbeit neue oder geänderte Dokumente?

Freundliche Erinnerung daran, dass, wenn neue/Änderungen an Dokumenten erforderlich sind, bis Freitag, 12. Juni, ein Platzhalter-PR gegen k/Website (Zweig dev-1.19 ) erforderlich ist.

@annajung das ist für den Kopf. Ja, es wird einige Änderungen an den seccomp-Dokumenten geben.

Hinzufügen von @hasheddan, der dies

Super, danke für das Update! Ich werde das Tracking-Blatt entsprechend ändern.
Bitte informieren Sie uns, sobald eine Platzhalter-PR gegen k/website erstellt wurde. Dankeschön!

@pjbgf -- Können Sie bitte hier alle

Der aktuelle Veröffentlichungsplan ist:

• ~Montag, 13. April: Woche 1 - Release-Zyklus beginnt~
• ~Dienstag, 19. Mai: Woche 6 – Verbesserungen einfrieren~
• Donnerstag, 25. Juni: Woche 11 - Code Freeze
• Donnerstag, 9. Juli: Woche 14 – Dokumente müssen ausgefüllt und überprüft werden
• Dienstag, 4. August: Woche 17 - Kubernetes v1.19.0 veröffentlicht

@palnabarun hier sind die aktuellen:
https://github.com/kubernetes/kubernetes/pull/91381
https://github.com/kubernetes/kubernetes/pull/91408
https://github.com/kubernetes/kubernetes/pull/91182
https://github.com/kubernetes/kubernetes/pull/91442

Ich habe auch eine Dachausgabe erstellt , die alle enthält.

Hi @pjbgf @hasheddan Nur eine freundliche Erinnerung, dass bis Freitag, 12. Juni, eine Platzhalter-PR gegen k/website fällig ist. Bitte lass es mich wissen, sobald du die PR gemacht hast, danke!

@annajung danke für die Erinnerung! Es wird bald geöffnet :+1:

Hallo @pjbgf -- Danke für die Erstellung des Umbrella-Problems. :+1:

Wir verfolgen das gleiche. :leicht_smiling_face:

Hallo @pjbgf -- wollte informieren .

Die Veröffentlichungszeitachse wurde kürzlich überarbeitet, weitere Details finden Sie hier .

Bitte lassen Sie es mich wissen, wenn Sie Fragen haben. :leicht_smiling_face:

Der überarbeitete Veröffentlichungsplan lautet:

• Donnerstag, 9. Juli: Woche 13 - Code Freeze
• Donnerstag, 16. Juli: Woche 14 - Dokumente müssen ausgefüllt und überprüft werden
• Dienstag, 25. August: Woche 20 - Kubernetes v1.19.0 veröffentlicht

Danke für das Update @palnabarun. Der Code ist größtenteils fertig, aber wir warten jetzt auf eine Nachprüfung. Insgesamt sehen wir immer noch gut aus. :+1:

Hallo @pjbgf @hasheddan , eine freundliche Erinnerung an die nächste Frist.
Bitte denken Sie daran, Ihren Platzhalter-Dokument-PR auszufüllen und bis Montag, den 6. Juli, zur Überprüfung vorzubereiten.

Hallo @pjbgf @hasheddan :wave:, Ich sehe, dass in https://github.com/kubernetes/kubernetes/issues/91286 noch 3 ausstehende Aktionselemente für implementierungsbezogene Änderungen und 1 ausstehende Aktionselement für die Dokumentation vorhanden sind. Glaubst du, dass sie es am Donnerstag, den 9. Juli, über den Code-Freeze schaffen werden?

Dankeschön. :leicht_smiling_face:

Code Freeze beginnt am Donnerstag, den 9. Juli EOD PST

@palnabarun docs PR ist größtenteils fertig und fügt nur einen speziellen Leitfaden für seccomp hinzu. Habe schon ein LGTM von @saschagrunert zu den aktuellen Änderungen. Danke, dass du uns hier auf dem Laufenden hältst :)

Hallo @hasheddan , danke für das obige Update. Nur eine kurze Erinnerung, um Ihre Doc-PR für die Überprüfung (Remove WIP/rebased/all ready to go) durch EOD vorzubereiten. Dankeschön!

@annajung wird es tun! Vielen Dank!

@hasheddan -- Danke für das Update. :Lächeln:

@pjbgf -- Ich habe gesehen, dass in https://github.com/kubernetes/kubernetes/issues/91286 zwei Kernaktionselemente noch zusammengeführt werden müssen und sich auch nicht im Zusammenführungspool befinden. Glaubst du, sie werden vor dem Code Freeze einsteigen?

Dankeschön. :leicht_smiling_face:

@palnabarun wir versuchen, es vor dem Einfrieren des Codes zu erledigen, schließlich war es bereits alles LGtm. Wir haben einige Probleme mit einigen flockigen Tests atm. 😅

Danke für die Vorwarnung.

Zur Verdeutlichung sind die 2 Prs, auf die wir warten, um zusammenzuführen:
https://github.com/kubernetes/kubernetes/pull/91408 und https://github.com/kubernetes/kubernetes/pull/92856

Letzteres (https://github.com/kubernetes/kubernetes/pull/92856) scheint eine Verifizierungsprüfung nicht zu bestehen. Laut https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700 ist hierfür ein Rebase/repush/rereview erforderlich, bevor es zusammengeführt werden kann.

@kikisdeliveryservice danke für die Klarstellung. Wir warten darauf, dass die flockigen Tests auf https://github.com/kubernetes/kubernetes/pull/91408 nicht mehr fehlschlagen. Sobald diese zusammengeführt sind, können wir den zweiten PR, der davon abhängt, neu aufbauen.

Hallo @pjbgf :wave:, Wir sind jetzt beim Code Freeze.

Da sich https://github.com/kubernetes/kubernetes/pull/91408 im Merge-Pool befindet und https://github.com/kubernetes/kubernetes/pull/92856 ein Rebase über https://github.com/ erfordert https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700 ist die beste Aktion hier, eine Ausnahmeanforderung zu stellen , um zusätzliche Zeit für die Fertigstellung des zweiten zu erhalten PR nach dem Merge-Pool wird klar.

Entfernen Sie die Erweiterung vorerst aus dem Meilenstein.

Dankeschön!

Am besten,
Kubernetes v1.19-Team für Release-Verbesserungen

/Meilenstein klar

Da sich kubernetes/kubernetes#91408 im Merge-Pool befindet und kubernetes/kubernetes#92856 laut kubernetes/kubernetes#92856 (Kommentar) ein Rebase über kubernetes/kubernetes#91408 erfordert, halten wir es für die beste Aktion, hier eine Ausnahme einzureichen Anfrage, um zusätzliche Zeit für den Abschluss des zweiten PR zu erhalten, nachdem der Zusammenführungspool freigegeben wurde.

Eine Neubasis auf einem genehmigten PR in der Zusammenführungswarteschlange erfordert keine Ausnahmeanforderung. Die PR war Code vollständig und wurde einen ganzen Tag vor Ablauf der Frist genehmigt.

Hallo @liggitt :wave:, danke für deine Inputs. :+1:

Wir werden die Verbesserung wieder in den Zyklus aufnehmen. Alle unsere Befürchtungen bezogen sich auf die Rebase. Da das sortiert ist, ist dies gut zu gehen. :leicht_smiling_face:

/Meilenstein v1.19

@pjbgf @saschagrunert @hasheddan -- danke für all eure Beiträge. :100:

Danke @palnabarun für das detaillierte Tracking der Verbesserung. Wir schätzen es! 🙏

@saschagrunert endlich die letzte PR kubernetes/kubernetes#92856 zusammenführen. Herzlichen Glückwunsch! Ich werde das Tracking-Sheet aktualisieren, um dies widerzuspiegeln.

@tallclair @pjbgf meinst du, wir können dieses Problem jetzt schließen, da seccomp GA ist?

@saschagrunert Normalerweise warten wir, bis die Veröffentlichung erfolgt, markieren dann den entsprechenden KEP als implemented und schließen dann das Verbesserungsproblem.

Bitte zögern Sie nicht, eine Änderung vorzunehmen , um implemented zu markieren. :leicht_smiling_face:

@saschagrunert Normalerweise warten wir, bis die Veröffentlichung erfolgt, markieren dann den entsprechenden KEP als implemented und schließen dann das Verbesserungsproblem.

Bitte zögern Sie nicht, eine Änderung vorzunehmen , um implemented zu markieren.

Vielen Dank für die Klarstellung, öffnete eine PR in https://github.com/kubernetes/enhancements/pull/1932

Die KEP wurde aktualisiert auf implementiert (PR endlich zusammengeführt!)

Bitte schließen Sie dieses Thema @saschagrunert

Vielen Dank an alle für Ihre Arbeit!!

/Meilenstein klar

/nah dran
Das ist erledigt.

@saschagrunert Ich kann mich nicht erinnern, ob wir dies schon einmal besprochen haben, aber gibt es einen Plan, die Anmerkungen schließlich zu bereinigen (dh die Unterstützung zu entfernen)? Der Hauptgrund dafür ist, dass Tools von Drittanbietern (z. B. Gatekeeper, Krail) nicht wissen müssen, um sowohl die Annotation als auch das Feld zu überprüfen

@saschagrunert Ich kann mich nicht erinnern, ob wir dies schon einmal besprochen haben, aber gibt es einen Plan, die Anmerkungen schließlich zu bereinigen (dh die Unterstützung zu entfernen)? Der Hauptgrund dafür ist, dass Tools von Drittanbietern (z. B. Gatekeeper, Krail) nicht wissen müssen, um sowohl die Annotation als auch das Feld zu überprüfen

Ja, dies ist für v1.23 geplant. Dies beinhaltet den (noch nicht erfolgten) Warnmechanismus, der ausgeführt werden kann, nachdem die erforderlichen Dienstprogrammfunktionen vorhanden sind (ref https://github.com/kubernetes/kubernetes/issues/94626).

Aus dem KEP:

Um auf die Verwendung von Anmerkungen aufmerksam zu machen (im Falle einer alten Automatisierung), wird ein Warnmechanismus verwendet, um darauf hinzuweisen, dass die Unterstützung in v1.23 eingestellt wird. Die in Betracht gezogenen Mechanismen sind Audit-Anmerkungen, Anmerkungen zum Objekt, Ereignisse oder eine Warnung, wie in KEP #1693 beschrieben.

…

Da wir bis zu 2 Minor-Releases von Versionsverzerrung zwischen Master und Node unterstützen, müssen Annotationen für mindestens 2 Versionen, die die ursprüngliche Implementierung bestanden haben, weiterhin unterstützt und aufgefüllt werden. Wir können jedoch beschließen, die Unterstützung weiter auszudehnen, um Brüche zu reduzieren. Wenn dieses Feature in v1.19 implementiert ist, schlage ich v1.23 als Ziel vor, um das alte Verhalten zu entfernen.

Ziehen Sie es vor, dieses Problem erneut zu öffnen, bis auch diese Bits implementiert sind?

Ja, lassen wir das offen, bis die Funktion vollständig abgeschlossen ist. Gibt es für die von Ihnen beschriebene Arbeit ein ak/k-Problem?

Ja, lassen wir das offen, bis die Funktion vollständig abgeschlossen ist. Gibt es für die von Ihnen beschriebene Arbeit ein ak/k-Problem?

Jetzt haben wir dort eine: https://github.com/kubernetes/kubernetes/issues/95171 :)