NIST SP 800-190 (Application Container Security)
Attestkeep rattache ce que l'admission control et le scan d'images de votre cluster ont enregistré sur une période à 15 exigences (source : NIST SP 800-190). 11 sont évaluées sur ces enregistrements ; 4 sont marquées hors périmètre, chacune avec la raison.
11 exigences à portée de cluster.
Références et titres tels que le rapport les imprime, c'est-à-dire en anglais. Ouvrez une exigence pour lire ce qu'elle demande, reformulé au plus près du texte de l'instrument.
Application Container Security Guide
NIST SP 800-190
Section 3 (risques) et section 4 (contre-mesures) pour les images, registries, orchestrateurs et containers
| Référence | Exigence | Sections du rapport |
|---|---|---|
| 3.1.1 / 4.1.1 | Image vulnerabilitiesLes images devraient être scannées en continu à la recherche de vulnérabilités, et les organisations devraient adopter des outils et des processus qui empêchent l'exécution d'images dont les vulnérabilités dépassent un seuil défini. | CoverageAdmission decisionsOutcomesControl statement |
| 3.1.2 / 4.1.2 | Image configuration defectsLes images devraient être contrôlées pour détecter les défauts de configuration, notamment l'exécution en root et d'autres réglages qui affaiblissent l'isolation sur laquelle repose un container. | Control statementAdmission decisions |
| 3.1.3 / 4.1.3 | Embedded malwareLes images devraient être surveillées à la recherche de fichiers malveillants, par une détection à base de signatures et par la provenance de l'image elle-même. | CoverageSupply chainControl statement |
| 3.1.5 / 4.1.5 | Use of untrusted imagesLes organisations devraient tenir un ensemble de registries et d'images de confiance, et empêcher les workloads d'exécuter des images venues d'ailleurs. | Control statementSupply chainAdmission decisions |
| 3.2.2 / 4.2.2 | Stale images in registriesLes organisations devraient s'assurer que seules des images à jour sont déployées, par exemple en désignant les images par des identifiants immuables plutôt que par des tags qu'on peut déplacer vers un contenu plus ancien. | Control statement |
| 3.2.3 / 4.2.3 | Insufficient authentication and authorization restrictionsL'accès aux registries devrait être restreint, et les images ne devraient être récupérées que depuis des registries que l'organisation contrôle ou a vérifiés. | Control statement |
| 3.3.1 / 4.3.1 | Unbounded administrative accessL'accès administrateur à l'orchestrateur devrait suivre le moindre privilège et, si possible, être fédéré à l'annuaire de l'organisation plutôt que reposer sur des comptes locaux distincts. | Evidence chain |
| 3.3.2 / 4.3.2 | Unauthorized accessSeuls les workloads autorisés devraient être admis dans le cluster, et chaque décision d'admission devrait être imputable. | Control statementAdmission decisionsEvidence chain |
| 3.4.4 / 4.4.4 | App vulnerabilitiesLes containers devraient être surveillés pour détecter les vulnérabilités découvertes après leur déploiement, à corriger dans des délais définis. | CoverageControl statementAdmission decisionsIssuesBreak-glass events |
| 4.1.1 (policy-driven enforcement) | Deviations from the control are governedQuand un container doit tourner malgré l'échec d'un contrôle, l'écart devrait être enregistré, justifié et limité dans le temps, plutôt qu'accordé en silence. | Triage decisionsEvidence chain |
| 6.4 (operations and maintenance) | The control operates continuouslyLes contre-mesures ci-dessus ne sont efficaces que tant qu'elles fonctionnent ; leur disponibilité fait elle-même partie du contrôle. | Availability |
4 exigences hors périmètre, et pourquoi
| Référence | Exigence et raison |
|---|---|
| 3.1.4 / 4.1.4 | Embedded clear text secrets Un admission controller lit les métadonnées et les vulnérabilités d'une image, pas le contenu de ses layers ; cet operator ne recherche pas de secrets dans le contenu des layers, et rien de tel n'est revendiqué ici. |
| 3.3.4 / 4.3.4 | Mixing of workload sensitivity levels La séparation des namespaces et le placement sur les nodes relèvent de la conception propre à l'exploitant du cluster ; ce contrôle décide quelles images peuvent tourner dans un namespace, pas comment les namespaces sont séparés entre eux. |
| 3.3.5 / 4.3.5 | Orchestrator node trust L'attestation des nodes et le durcissement des hôtes échappent à la vue d'un admission controller ; ce document dit ce qui peut tourner, pas où. |
| 3.4.1 / 4.4.1 | Vulnerabilities within the runtime software Le runtime fait partie de la plateforme hôte ; cet operator rend compte des images qu'il admet et de sa propre disponibilité, pas de la version du runtime. |
Preuves tirées des journaux que tient déjà le cluster.
Rien n'est rempli à la main. La réponse à chaque exigence porte un statut (satisfaite, partielle, écart ou hors périmètre), une note avec les chiffres de la période et les sections du rapport d'où viennent ces chiffres.
Ce sur quoi s'appuie le mapping
Chaque exigence évaluée reçoit sa réponse d'une ou plusieurs de ces affirmations sur les enregistrements de la période. La même affirmation répond à la même question dans tous les frameworks : deux rapports sur une même période ne peuvent pas diverger.
- L'admission refuse les workloads non conformes3 exigences
- Chaque décision et chaque action d'administration est enregistrée3 exigences
- Chaque image de l'inventaire a un enregistrement de scan3 exigences
- Seules les images de provenance établie peuvent tourner2 exigences
- Les images n'entrent que depuis des registries désignés2 exigences
- L'accès administrateur est fédéré à un annuaire1 exigence
- Le contrôle lui-même a fonctionné pendant toute la période1 exigence
- Les workloads désignent les images par digest, pas par un tag mobile1 exigence
- Les risques acceptés sont nommés, justifiés et expirent1 exigence
- Un refus ou une vulnérabilité critique parvient à une personne1 exigence
- Un délai de correction est déclaré pour chaque sévérité1 exigence
- Les images portant des vulnérabilités graves sont refusées1 exigence
- Les privilèges des workloads sont limités à l'admission1 exigence
Ce que contient le rapport.
Chaque paquet contient les mêmes sections, quel que soit le framework. Les sections signalées sont celles que citent les réponses pour NIST SP 800-190, avec le nombre d'exigences qui renvoient à chacune.
- 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)
Le paragraphe de périmètre, tel que le rapport l'imprime (en anglais).
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.
Sur NIST SP 800-190
Est-ce une certification selon NIST SP 800-190 ?
Non. Le paquet est une preuve produite à partir des enregistrements de votre cluster. Ce n'est pas une certification, et aucun auditeur n'est tenu de l'accepter. Le paragraphe de périmètre de cette page est celui que porte le rapport lui-même.
Pourquoi 4 exigences sont-elles hors périmètre ?
Elles portent sur des choses que les enregistrements d'admission et de scan d'un cluster ne peuvent pas montrer. Elles figurent avec la raison au lieu d'être omises, pour que le lecteur du rapport voie que l'exclusion est voulue.
Quel plan inclut NIST SP 800-190 ?
Tous les plans peuvent produire un rapport selon ce framework. Community et Team incluent un framework au choix, Business trois, Enterprise tous. Les prix sont sur la page des tarifs.
Comment un auditeur vérifie-t-il le paquet ?
Dans un navigateur, sur attestkeep.com/verify.html, où rien n'est envoyé, ou avec le court script du site de documentation. Aucun des deux n'a besoin de nous. La page Pour les auditeurs donne le détail.
Installez-le vous-même.
Créez un compte, confirmez votre e-mail avec le code envoyé, prenez la clé Community gratuite sur la page Licences et installez avec Helm.
Créer un compte