NIST SP 800-190 (Application Container Security)
Was Admission Control und Image-Scan Ihres Clusters in einem Zeitraum erfasst haben, ordnet Attestkeep 15 Anforderungen zu (Quelle: NIST SP 800-190). 11 davon werden aus diesen Einträgen bewertet; 4 sind als außerhalb des Umfangs markiert, jede mit Begründung.
11 Anforderungen aus Clustersicht.
Fundstellen und Titel so, wie der Bericht sie druckt, also auf Englisch. Öffnen Sie eine Anforderung, um zu lesen, was sie verlangt – nah am Wortlaut des Regelwerks wiedergegeben.
Application Container Security Guide
NIST SP 800-190
Abschnitt 3 (Risiken) und Abschnitt 4 (Gegenmaßnahmen) für Images, Registries, Orchestratoren und Container
| Fundstelle | Anforderung | Berichtsabschnitte |
|---|---|---|
| 3.1.1 / 4.1.1 | Image vulnerabilitiesImages sollen laufend auf Schwachstellen gescannt werden, und Organisationen sollen Werkzeuge und Prozesse einsetzen, die verhindern, dass Images mit Schwachstellen über einer festgelegten Schwelle laufen. | CoverageAdmission decisionsOutcomesControl statement |
| 3.1.2 / 4.1.2 | Image configuration defectsImages sollen auf Konfigurationsmängel geprüft werden, etwa den Betrieb als root und andere Einstellungen, die die Isolation schwächen, auf die sich ein Container verlässt. | Control statementAdmission decisions |
| 3.1.3 / 4.1.3 | Embedded malwareImages sollen auf schädliche Dateien überwacht werden, mit signaturbasierter Erkennung und anhand der Herkunft des Images selbst. | CoverageSupply chainControl statement |
| 3.1.5 / 4.1.5 | Use of untrusted imagesOrganisationen sollen eine Menge vertrauenswürdiger Registries und Images pflegen und verhindern, dass Workloads Images aus anderen Quellen ausführen. | Control statementSupply chainAdmission decisions |
| 3.2.2 / 4.2.2 | Stale images in registriesOrganisationen sollen sicherstellen, dass nur aktuelle Images ausgerollt werden, etwa indem sie Images über unveränderliche Kennungen ansprechen statt über Tags, die auf älteren Inhalt umgehängt werden können. | Control statement |
| 3.2.3 / 4.2.3 | Insufficient authentication and authorization restrictionsDer Zugriff auf Registries soll eingeschränkt sein, und Images sollen nur aus Registries bezogen werden, die die Organisation kontrolliert oder geprüft hat. | Control statement |
| 3.3.1 / 4.3.1 | Unbounded administrative accessAdministrativer Zugriff auf den Orchestrator soll nach dem Prinzip der minimalen Rechte erfolgen und, wo möglich, über das Verzeichnis der Organisation statt über eigene lokale Konten laufen. | Evidence chain |
| 3.3.2 / 4.3.2 | Unauthorized accessNur autorisierte Workloads sollen im Cluster zugelassen werden, und jede Admission-Entscheidung soll zurechenbar sein. | Control statementAdmission decisionsEvidence chain |
| 3.4.4 / 4.4.4 | App vulnerabilitiesContainer sollen auf Schwachstellen überwacht werden, die nach dem Ausrollen entdeckt wurden, und diese sollen innerhalb festgelegter Fenster behoben werden. | CoverageControl statementAdmission decisionsIssuesBreak-glass events |
| 4.1.1 (policy-driven enforcement) | Deviations from the control are governedMuss ein Container trotz einer fehlgeschlagenen Prüfung laufen, soll die Abweichung festgehalten, begründet und befristet werden, statt stillschweigend gewährt zu werden. | Triage decisionsEvidence chain |
| 6.4 (operations and maintenance) | The control operates continuouslyDie genannten Gegenmaßnahmen wirken nur, solange sie laufen; ihre Verfügbarkeit ist selbst Teil der Kontrolle. | Availability |
4 Anforderungen außerhalb des Umfangs, und warum
| Fundstelle | Anforderung und Grund |
|---|---|
| 3.1.4 / 4.1.4 | Embedded clear text secrets Ein Admission Controller liest die Metadaten und Befunde eines Images, nicht den Inhalt seiner Layer; nach Secrets im Layer-Inhalt sucht dieser Operator nicht, und das wird hier auch nicht behauptet. |
| 3.3.4 / 4.3.4 | Mixing of workload sensitivity levels Trennung von Namespaces und Platzierung auf Nodes sind das eigene Design des Cluster-Betreibers; diese Kontrolle regelt, welche Images in einem Namespace laufen dürfen, nicht wie Namespaces voneinander getrennt sind. |
| 3.3.5 / 4.3.5 | Orchestrator node trust Node-Attestation und Härtung des Hosts liegen außerhalb der Sicht eines Admission Controllers; dieses Dokument sagt, was laufen darf, nicht wo. |
| 3.4.1 / 4.4.1 | Vulnerabilities within the runtime software Die Runtime gehört zur Host-Plattform; dieser Operator berichtet über die Images, die er zulässt, und über seine eigene Verfügbarkeit, nicht über die Version der Runtime. |
Nachweise aus Einträgen, die der Cluster ohnehin führt.
Nichts wird von Hand ausgefüllt. Jede Antwort zu einer Anforderung trägt einen Status (erfüllt, teilweise, Lücke oder außerhalb des Umfangs), eine Notiz mit den Zahlen des Zeitraums und die Berichtsabschnitte, aus denen diese Zahlen stammen.
Worauf sich das Mapping stützt
Jede bewertete Anforderung wird durch eine oder mehrere dieser Aussagen über die Einträge des Zeitraums beantwortet. Dieselbe Aussage beantwortet dieselbe Frage in jedem Framework; zwei Berichte über denselben Zeitraum können sich daher nicht widersprechen.
- Admission lehnt nicht konforme Workloads ab3 Anforderungen
- Jede Entscheidung und jede administrative Aktion wird festgehalten3 Anforderungen
- Jedes Image im Bestand hat einen Scan-Eintrag3 Anforderungen
- Nur Images mit nachgewiesener Herkunft dürfen laufen2 Anforderungen
- Images kommen nur aus benannten Registries2 Anforderungen
- Administrativer Zugang läuft über ein Verzeichnis1 Anforderung
- Die Kontrolle selbst lief den ganzen Zeitraum1 Anforderung
- Workloads referenzieren Images per Digest, nicht per verschiebbarem Tag1 Anforderung
- Akzeptierte Risiken sind benannt, begründet und laufen ab1 Anforderung
- Eine Ablehnung oder ein kritischer Befund erreicht eine Person1 Anforderung
- Für jeden Schweregrad ist ein Behebungsfenster festgelegt1 Anforderung
- Images mit schweren Befunden werden abgelehnt1 Anforderung
- Workload-Privilegien werden bei der Admission begrenzt1 Anforderung
Was der Bericht enthält.
Jedes Paket enthält dieselben Abschnitte, unabhängig vom Framework. Markiert sind die, auf die sich die Antworten zu NIST SP 800-190 stützen, jeweils mit der Zahl der Anforderungen, die auf sie verweisen.
- Organisation
- Framework mapping
- Cluster
- Control statement8
- Coverage3
- Vulnerability findings
- Outcomes1
- Admission decisions5
- Supply chain2
- Triage decisions1
- Break-glass events1
- Availability1
- Evidence chain3
- Deployment context
- Issues1
- Ledger
- Population
- Runtime events
- Producer statements (VEX)
Geltungsbereich, wörtlich aus dem Bericht (Englisch).
This document reports what one Kubernetes cluster's admission control and image scanning recorded during the period, mapped onto NIST SP 800-190. The guide covers images, registries, orchestrators, containers and host operating systems; this operator observes the first three at the point a workload is admitted. Runtime behaviour inside a running container, and the hardening of the hosts themselves, are outside what an admission controller can see and are marked as such rather than claimed.
Fragen zu NIST SP 800-190
Ist das eine Zertifizierung nach NIST SP 800-190?
Nein. Das Paket ist ein Nachweis aus den clustereigenen Einträgen. Es ist keine Zertifizierung, und kein Auditor muss es anerkennen. Der Absatz zum Geltungsbereich auf dieser Seite ist derselbe, den auch der Bericht enthält.
Warum liegen 4 Anforderungen außerhalb des Umfangs?
Sie fragen nach Dingen, die die Admission- und Scan-Einträge eines einzelnen Clusters nicht zeigen können. Sie werden mit Begründung aufgeführt statt weggelassen, damit jeder Leser des Berichts sieht, dass der Ausschluss bewusst ist.
Welcher Plan enthält NIST SP 800-190?
Jeder Plan kann danach berichten. Community und Team enthalten 1 Framework Ihrer Wahl, Business 3, Enterprise alle. Die Preise stehen auf der Preisseite.
Wie prüft ein Auditor das Paket?
Im Browser unter attestkeep.com/verify.html, wo nichts hochgeladen wird, oder mit dem kurzen Skript auf der Dokumentationsseite. Beides kommt ohne uns aus. Einzelheiten stehen unter Für Auditoren.
Selbst installieren.
Konto anlegen, die E-Mail mit dem zugesandten Code bestätigen, den kostenlosen Community-Schlüssel auf der Seite Licences holen und mit Helm installieren.
Konto anlegen