cfn_nag
v0.8.10
Das CFN-NAG-Tool sucht nach Mustern in Cloudformationsvorlagen, die auf unsichere Infrastruktur hinweisen können. Grob gesagt wird es nach:
Weitere Hintergrundinformationen zum Tool finden Sie in diesem Beitrag in Stelligents Blog:
Das Finden von Sicherheitsproblemen zu Beginn des Entwicklungsprozesses einer CloudFormation-Vorlage mit "CFN-nag" finden
Vermutet Ruby> = 2.5.x ist installiert, die Installation ist nur eine Frage von:
gem install cfn-nagAuf macOS oder Linux können Sie alternativ mit Brew installieren:
brew install ruby brew-gem
brew gem install cfn-nag Um cfn_nag als Aktion in CodePipeline auszuführen, können Sie über das AWS Serverless Application Repository bereitgestellt werden.
Ausführen:
cfn_nag_scan --input-path < path to cloudformation json > Der Pfad kann ein Verzeichnis oder eine bestimmte Vorlage sein. Wenn es sich um ein Verzeichnis handelt, werden alle .json, .template , .yml und .yaml -Dateien verarbeitet, einschließlich der Wiederholung in Unterverzeichnisse.
Das Standardausgangsformat ist freier Formentext, aber JSON-Ausgabe kann mit dem --output-format json ausgewählt werden.
Optional entlastet ein --debug -Flag Informationen über die Interna der Regellade.
Führen Sie mit --help für eine vollständige Auflistung unterstützter Switches aus.
Um eine Liste aller Regeln zu sehen, die derzeit CFN-NAG unterstützt, gibt es ein Befehlszeilen-Dienstprogramm, das sie in STDOut abgelegt hat:
cfn_nag_rules Eine Dockerfile wird für die Bequemlichkeit bereitgestellt. Es wird auf DockerHub als stelligent/cfn_nag veröffentlicht.
https://hub.docker.com/r/stelligent/cfn_nag
Sie können es auch lokal bauen.
docker build -t stelligent/cfn_nag .Sie können ein lokales Verzeichnis mit Vorlagen in den Docker -Container montieren und dann CFN_NAG im Container aufrufen. In diesem Beispiel werden die Testvorlagen verwendet, die in Unit -Testing CFN_NAG verwendet werden:
$ docker run -v ` pwd ` /spec/test_templates:/templates -t stelligent/cfn_nag /templates/json/efs/filesystem_with_encryption.json
{
" failure_count " : 0,
" violations " : [
]
}
$ docker run -v ` pwd ` /spec/test_templates:/templates -t stelligent/cfn_nag /templates/json/efs/filesystem_with_no_encryption.json
{
" failure_count " : 1,
" violations " : [
{
" id " : " F27 " ,
" type " : " FAIL " ,
" message " : " EFS FileSystem should have encryption enabled " ,
" logical_resource_ids " : [
" filesystem "
]
}
]
} cfn_nag_scan kann als Teil eines Github -Workflows ausgeführt werden, um Code während kontinuierlicher Integrationspipelines zu bewerten.
Erstellen Sie in Ihrer GitHub -Workflow -Datei einen Schritt, der die Aktion cfn_nag verwendet:
- name : Simple test
uses : stelligent/cfn_nag@master
with :
input_path : testsWeitere Informationen zur GitHub -Aktion finden Sie hier.
CFN-NAG unterstützt den Begriff eines "Profils", das effektiv eine zulässige Liste der zu beantragten Regeln ist. Das Profil ist eine Textdatei, die eine Regelkennung pro Zeile enthalten muss. Wenn CFN-NAG über das Befehlszeilenargument --profile-path -Befehlszeile angegeben ist, wird CFN-NAG nur Verstöße aus diesen bestimmten Regeln zurückgeben.
Die Motivation für das Erstellen eines "Profils" besteht darin, dass sich unterschiedliche Entwickler möglicherweise für unterschiedliche Regeln kümmern. Beispielsweise könnte sich ein "Infrastructure_Developer" um IAM -Regeln kümmern, während ein "App_Developer" möglicherweise nicht einmal in der Lage ist, IAM -Ressourcen zu erstellen und sich daher nicht für diese Regeln zu kümmern.
Hier ist ein Beispielprofil:
F1
F2
F27
W3
W5
Die Verweigerungsliste ist im Grunde das Gegenteil des Profils: Es handelt sich um eine Liste von Regeln, die Sie niemals angewendet haben. Wenn CFN-NAG über das Befehlszeilenargument --deny-list-path Befehlszeile angegeben ist, wird sie niemals Verstöße aus den in der Datei angegebenen Regeln zurückgeben.
Falls eine Regel in beiden Fällen angegeben ist, hat die Liste der Ablehnungsliste Vorrang vor dem Profil, und die Regel wird nicht angewendet.
Das Format ist wie folgt. Die einzigen zwei hervorstechenden Felder sind RulesToSuppress und die id pro Artikel. Der reason wird nicht von CFN-Nag interpretiert, aber es wird empfohlen, zu rechtfertigen und zu dokumentieren, warum die Regel niemals angewendet werden sollte.
RulesToSuppress :
- id : W3
reason : W3 is something we never care about at enterprise X Für den Fall, dass es eine Regel gibt, die Sie unterdrücken möchten, kann die betroffene Ressource ein cfn_nag Metadata hinzugefügt werden, um CFN_NAG zu sagen, dass sie keinen Fehler oder eine Warnung für diese Regel anziehen soll.
Wenn Sie beispielsweise eine öffentlich ausgerichtete ELB einrichten, die für eingehende Verbindungen aus dem Internet offen steht, mit Ressourcen wie folgt:
public_alb.yaml
# Partial template
PublicAlbSecurityGroup :
Properties :
GroupDescription : ' Security group for a public Application Load Balancer '
VpcId :
Ref : vpc
Type : AWS::EC2::SecurityGroup
PublicAlbSecurityGroupHttpIngress :
Properties :
CidrIp : 0.0.0.0/0
FromPort : 80
GroupId :
Ref : PublicAlbSecurityGroup
IpProtocol : tcp
ToPort : 80
Type : AWS::EC2::SecurityGroupIngressCFN_NAG wird Warnungen wie folgt anziehen:
$ cfn_nag_scan -i public_alb.yaml
------------------------------------------------------------
public_alb.yaml
------------------------------------------------------------------------------------------------------------------------
| WARN W9
|
| Resources: [ " PublicAlbSecurityGroup " ]
|
| Security Groups found with ingress cidr that is not /32
------------------------------------------------------------
| WARN W2
|
| Resources: [ " PublicAlbSecurityGroup " ]
|
| Security Groups found with cidr open to world on ingress. This should never be true on instance. Permissible on ELB
Failures count: 0
Warnings count: 2Durch Hinzufügen der Metadaten können diese Warnungen unterdrückt werden:
public_alb_with_suppression.yaml
# Partial template
PublicAlbSecurityGroup :
Properties :
GroupDescription : ' Security group for a public Application Load Balancer '
VpcId :
Ref : vpc
Type : AWS::EC2::SecurityGroup
Metadata :
cfn_nag :
rules_to_suppress :
- id : W9
reason : " This is a public facing ELB and ingress from the internet should be permitted. "
- id : W2
reason : " This is a public facing ELB and ingress from the internet should be permitted. "
PublicAlbSecurityGroupHttpIngress :
Properties :
CidrIp : 0.0.0.0/0
FromPort : 80
GroupId :
Ref : PublicAlbSecurityGroup
IpProtocol : tcp
ToPort : 80
Type : AWS::EC2::SecurityGroupIngress $ cfn_nag_scan -i public_alb_with_suppression.yaml
------------------------------------------------------------
public_alb_with_supression.yaml
------------------------------------------------------------
Failures count: 0
Warnings count: 0CloudFormation -Vorlagenparameter können ein Problem für die statische Analyse darstellen, da die Werte am Zeitpunkt der Bereitstellung angegeben werden. Mit anderen Worten, die Werte sind nicht verfügbar, wenn die statische Analyse durchgeführt wird. Die statische Analyse kann nur den "Code" untersuchen, der sich vor ihm befindet. Daher wird eine Sicherheitsgruppe Eingangsregel von 0.0.0.0/0 nicht markiert, wenn das CIDR parametrisiert ist und der 0.0.0.0/0 zum Zeitpunkt der Bereitstellung übergeben wird.
Um das Überprüfen der Parameterwerte zuzulassen, kann ein Benutzer die Parameterwerte in einer JSON-Datei angeben, die in der Befehlszeile sowohl an cfn_nag als auch an cfn_nag_scan mit dem --parameter-values-path=<filename/uri> Flag übergeben wurde.
Das Format des JSON ist ein einzelner Schlüssel, "Parameter", dessen Wert ein Wörterbuch mit jedem Schlüssel-/Wert -Paar -Zuordnung zu den Parametern ist:
{
"Parameters" : {
"Cidr" : " 0.0.0.0/0 "
}
}Dadurch werden dem folgenden Parameter "0.0.0.0/0" bereitgestellt:
Parameters :
Cidr :
Type : String Vorsicht , wenn es zusätzliche Parameter im JSON gibt, werden sie leise ignoriert (damit cfn_nag_scan denselben JSON auf alle Vorlagen anwenden kann).
Wenn der JSON fehlerhaft ist oder die obige Spezifikation nicht erfüllt, scheitert das Parsen mit einem tödlichen Verstoß.
Vor 0.5.55 wurden die Anrufe bei FN :: FindInmap effektiv ignoriert. Das zugrunde liegende Modell würde sie sein, und so würden sie als Hash -Werte für Regeln erscheinen. Zum Beispiel: { "Fn::FindInMap" => [map1, key1, key2]}
Ab 0.5.55 versucht das Modell, den Wert für einen Aufruf zur FindingInmap zu berechnen und diesen Wert den Regeln zu präsentieren. Diese Bewertung unterstützt Schlüssel, die sind:
Wenn die Bewertungslogik den Wert für einen Schlüssel nicht ermitteln kann, wird sie das alte Verhalten der Rückgabe des Hashs für den gesamten Ausdruck standardmäßig ermitteln.
Ebenfalls vor 0.5.55 wurden die Aufrufe der AWS -Pseudofunktionen effektiv ignoriert. Das zugrunde liegende Modell würde sie sein, und so würden sie als Hash -Werte für Regeln erscheinen. Zum Beispiel: {"Ref"=>"AWS::Region"} . Ein häufiger Anwendungsfall besteht darin, Zuordnungen nach Region zu organisieren, sodass die Bewertung der Pseudofunktion für eine bessere Unterstützung der Kartenbewertung wichtig ist.
Ab 0.5.55 wird das Modell die folgenden AWS -Pseudofunktionen für Regeln mit den Standardwerten darstellen:
'AWS::URLSuffix' => 'amazonaws.com',
'AWS::Partition' => 'aws',
'AWS::NotificationARNs' => '',
'AWS::AccountId' => '111111111111',
'AWS::Region' => 'us-east-1',
'AWS::StackId' => 'arn:aws:cloudformation:us-east-1:111111111111:stack/stackname/51af3dc0-da77-11e4-872e-1234567db123',
'AWS::StackName' => 'stackname'
Zusätzlich kann der Endbenutzer den Wert über den herkömmlichen Parametersubstitutionsmechanismus überschreiben. Zum Beispiel:
{
"Parameters" : {
"AWS::Region" : " eu-west-1 "
}
}Bis zur Version 0.4.66 von CFN_NAG hat das zugrunde liegende Modell keine Verarbeitung von Fn :: in einer Vorlage durchgeführt. Dies bedeutete, dass, wenn eine Eigenschaft einen bedingten Wert hatte, es an der Regel war, das Fn :: if zu analysieren. Angesichts der Tatsache, dass ein Fn ::, wenn es fast überall erscheinen könnte, für Regelentwickler eine Whack-a-Mol-Situation erzeugt. Bestenfalls könnte die Regellogik Werte ignorieren, die davon ausgehen, dass der Wert überhaupt kein Hash war.
Um dieses Problem anzugehen, besteht das Standardverhalten für CFN_NAG nun darin, Fn :: wenn mit dem wahren Ergebnis zu ersetzen. Dies bedeutet standardmäßig, dass Regeln die falschen Ergebnisse nicht auf Sicherheitsverstöße untersuchen.
Zusätzlich zum Ersetzen von Fn ::, wenn auf der Eigenschaftswertebene das gleiche Verhalten auf fn :: angewendet wird, wenn es auf der obersten Ebene der Eigenschaften ist. Zum Beispiel:
Resource1 :
Type : Foo
Properties : !If
- IsNone
- Description : Up
- Description : DOwnWird genauso aussehen wie:
Resource1 :
Type : Foo
Properties :
Description : Up Um dieses Verhalten zu kontrollieren, kann ein Benutzer die Bedingungswerte in einer JSON-Datei angeben, die die Befehlszeile sowohl an cfn_nag als auch an cfn_nag_scan mit dem Flag --condition-values-path=<filename/uri> übergeben hat.
Das Format des JSON ist ein AA -Wörterbuch mit jeder Zuordnung von Schlüssel-/Wertpaaren zu den Bedingungen:
{
"Condition1" : true ,
"Condition2" : false
}Die Grundlage für SPCM wird im Blog -Post -Gedanken -Experiment beschrieben, die die Komplexitätsmetrik für IAM -Richtliniendokumente vorgeschlagen haben.
Ab Version 0.6.0 von CFN_NAG:
spcm_scan kann ein Verzeichnis von CloudFormation -Vorlagen (wie CFN_NAG_SCAN) scannen und einen Bericht mit den SPCM -Metriken im JSON- oder im HTML -Format erstellencfn_nag_scan --rule-arguments spcm_threshold:100--rule-arguments zu akzeptieren. Das Regelobjekt muss nur einen attr_accessor deklarieren, --rule-arguments attr_accessor :spcm_threshold Die Veröffentlichung von 0.5.x enthält einige wesentliche Änderungen in der Verteilung und geladener Art von benutzerdefinierten Regeln (CAN). Vor dieser Veröffentlichung gab es zwei Orte, an denen Regeln geladen wurden: das Verzeichnis lib/cfn-nag/custom_rules im Core CFN_NAG-Edelstein und das in der Befehlszeile angegebene Custom-Rule-Verzeichnis.
Es gibt zwei Anwendungsfälle, die eine Neugestaltung darüber erzwangen, wie/wo benutzerdefinierte Regeln geladen werden. Der Regelbelastungsmechanismus wurde verallgemeinert, sodass benutzerdefinierte Regelrepositorys verwendet werden können, um Regeln zu entdecken.
Eine Reihe von "Regeldateien", die in einem Dateisystem herumtrieben werden, ist aus der Sicht der herkömmlichen Softwareentwicklung nicht großartig. Es gibt keine Version oder Rückverfolgbarkeit in diesen Dateien, also führt 0.5.x den Begriff eines "cfn_nag -Regeljuweles" ein. Ein Entwickler kann als Teil eines separaten Edelsteins benutzerdefinierte Regeln entwickeln und es installieren ... und diese Regeln werden von CFN_NAG verwiesen, solange die GEM -Metadaten cfn_nag_rules => true enthält. Für ein Juwel mit dem Namen "CFN-Nag-Hipaa-Rules" wird jeder *.rb unter lib/cfn-nag-hipaa-Rules geladen. Alle benutzerdefinierten Regeln sollten von CFNNAG :: Baserule in CFN-nag/Base_RUE ( nicht CFN-NAG/Custom-Rules/Base) abgeleitet. Wenn die Regel von etwas anderem abgeleitet werden muss, definieren Sie eine Methode cfn_nag_rule? Das true führt auch dazu, dass es in der Regel geladen wird.
Wenn CFN_NAG in einem AWS -Lambda ausgeführt wird, gibt es im traditionellen Sinne kein Dateisystem (neben /tmp). Daher sind nur Kernregeln aus der Lambda verwendbar. Um benutzerdefinierte Regeln zu unterstützen, unterstützt CFN_NAG die Entdeckung von Regeln aus einem S3 -Bucket anstelle des Dateisystems.
Alles, was Sie wahrscheinlich gesehen haben, wie Sie benutzerdefinierte Regeln in Ruby entwickeln können, gilt immer noch.
Um Regeln aus einem S3 -Bucket zu entdecken, erstellen Sie eine Datei s3.yml mit diesem Inhalt:
---
repo_class_name : S3BucketBasedRuleRepo
repo_arguments :
s3_bucket_name : cfn-nag-rules-my-enterprise
prefix : /rulesSo wenden Sie *rel.rb-Dateien im Bucket CFN-Nag-Rules-My-Enterprise mit den Präfix /Regeln (z. B. /Rules/Mynewrule.rb) an, geben Sie diese Datei in der Befehlszeile zu cfn_nag als solches an:
cat my_cfn_template.yml | cfn_nag --rule-repository s3.yml Wenn Regeln in mehr als einem Bucket sind, erstellen Sie mehrere S3*.yml-Dateien und geben Sie diese im Argument- --rule-repository an.
Wenn die AMBient AWS-Anmeldeinformationen die Erlaubnis haben, auf den Bucket cfn-nag-rules-enterprise zuzugreifen, finden Sie alle Regeln wie /rules/*Rule.rb . Wenn ein bestimmtes AWS_Profile verwendet werden sollte, fügen Sie es als Schlüssel unter repo_arguments hinzu, z. B. aws_profile: my_aws_profile
Über das Dateisystem hinaus installiert GEM und S3 - die neue Architektur unterstützt theoretisch die Entwicklung anderer "Regelrepositories", um Regeln aus DynamoDB, relationalen Datenbanken oder anderen Webdiensten zu laden.
Um neue Regeln für Ihren eigenen Gebrauch und/oder Community -Beitrag zu erfassen, finden Sie Einzelheiten zur Entwicklung benutzerdefinierter Regel.
Ein Screencast, der die TDD-Custom-Regelentwicklung für Suppe zu Nusss zeigt, ist hier erhältlich:
https://www.youtube.com/watch?v=jrzct0NAFD4&t=1601S
Um die Spezifikationen auszuführen, müssen Sie sicherstellen
gem install bundle
bundle install Um alle Spezifikationen auszuführen, führen Sie einfach rake test:all .
Um die End-to-End-Tests durchzuführen, führen Sie rake test:e2e . Das Skript bündelt alle Edelsteine in der GemFile, erstellt und installiert das CFN_NAG -Gem lokal, installieren Spezifikationen abhängig und führen dann Tests aus, die mit 'end_to_end' markiert sind. Außerdem werden die von Amazon bereitgestellten Beispielvorlagen heruntergezogen und CFN_NAG_SCAN gegen sie ausgeführt, um festzustellen, ob bekannte gute Vorlagen Ausnahmen innerhalb von CFN-NAG verursachen.
So installieren Sie die aktuelle GIT -Filiale lokal:
bundle install
scripts/deploy_local.shEs gibt eine vollständige Umgebung für Fernentwicklungen und Einrichtungen mit allen Tools und Einstellungen, die vorkonfiguriert sind, um die Regelentwicklung und -erschaffung zu erleichtern. Sie können dies mit der VS -Code -Remote -Entwicklungsfunktion aktivieren.
Folder contains a dev container configuration file. Reopen folder to develop in a container Klicken Sie auf die Schaltfläche Reopen in Container[Dev Container] cfn_nag DevelopmentWeitere Informationen zum VS -Code -Remote -Entwicklungsaufbau finden Sie hier, VS Code Remote -Entwicklung.
Um einen Fehler zu melden oder eine Funktion anzufordern, senden Sie ein Problem über das Github -Repository über: https://github.com/stelligent/cfn_nag/issues/new
