AWS-Konfigurationsregeln schreiben

Mit AWS Config-Regeln können Sie feststellen, ob eine Ressource konform ist oder nicht. Wenn Sie früher benutzerdefinierte Prüfungen durchführen wollten, mussten Sie AWS Lambda-Funktionen schreiben, um die Konfiguration einer Ressource zu validieren. Seit dem 2. August 2022 haben Sie die Möglichkeit, cfn-guard Regeln zu verwenden, um dasselbe zu erreichen.

Warum sollte ich cfn-guard verwenden?

Das Schreiben einer Lambda-Funktion ist nicht schwierig. Aber es wird schwieriger, wenn Sie Unit-Tests hinzufügen. Wenn Sie Ihren Compliance-Status auf der Grundlage einer Lambda-Funktion bestimmen, möchten Sie sicherstellen, dass sie wie vorgesehen funktioniert. Das ist der Vorteil von cfn-guard, Sie schreiben eine Regel und Sie schreiben einige Tests. Diese Tests bestehen aus ein paar Schnipseln yaml und pro Schnipsel definieren Sie, ob Ihre Regel funktionieren soll: PASS, FAIL oder SKIP.

Der andere Vorteil von cfn-guard ist, dass Sie eine einzige Möglichkeit haben, Regeln zu schreiben. Am 8. November 2022 hielt ich einen Vortrag zu diesem Thema bei der AWS User Group NL. In diesem Vortrag habe ich die Unterschiede zwischen detektiven und präventiven Kontrollen hervorgehoben. Die Verwendung von cfn-guard Regeln in AWS Config ist eine detektivische Kontrolle. Aber dieselbe Sprache kann auch zur Erstellung präventiver Kontrollen verwendet werden!

Ja, ich sagte Sprache und nicht Regeln

Es stellt sich heraus, dass die für AWS Config geschriebenen Regeln nicht zur Validierung von AWS CloudFormation-Vorlagen verwendet werden können. Sie sind ähnlich, aber anders! Eine AWS Config-Regel hat die folgende Struktur:

{
  "version": "1.3",
  "arn": "arn:aws:s3:::aws-meetup-2022-11-08-noncompliantbucket-xxxxxxxxxxxxx",
  "resourceType": "AWS::S3::Bucket",
  "resourceId": "aws-meetup-2022-11-08-noncompliantbucket-xxxxxxxxxxxxx",
  "resourceName": "aws-meetup-2022-11-08-noncompliantbucket-xxxxxxxxxxxxx",
  "awsRegion": "eu-west-1",
  "supplementaryConfiguration": {
    "ServerSideEncryptionConfiguration": {
        "rules": [
            { "applyServerSideEncryptionByDefault": {"sseAlgorithm": "aws:kms"} }
        ]
    }
  }
}

Eine CloudFormation-Vorlage hat die folgende Struktur:

{
    "Resources": {
        "NonCompliantBucket": {
            "Type": "AWS::S3::Bucket",
            "Properties": {
                "BucketEncryption": {
                    "ServerSideEncryptionConfiguration": [
                        {
                            "ServerSideEncryptionByDefault": {
                                "SSEAlgorithm": "aws:kms"
                            }
                        }
                    ]
                }
            }
        },
        "OtherResource": { ... }
    }
}

Das erste, was Sie sehen können, ist, dass die AWS Config-Regel nur den Kontext der Ressource hat, die sie validiert. Die CloudFormation-Vorlage hingegen hat eine oder mehrere Ressourcen. Sie können also die beiden Standorte wie folgt vergleichen:

supplementaryConfiguration gegen Resources > NonCompliantBucket > Properties

Aber wenn Sie genauer hinsehen, stellen Sie auch fest, dass die Struktur und die Benennung unterschiedlich sind. Das heißt, Sie sind dazu verdammt, 2 Arten von Regeln zu pflegen. 1 für AWS Config (Detective) und 1 für CloudFormation (Preventive).

Warum sollten Sie eine detektivische und eine präventive Regel schreiben?

Die Antwort ist, dass Sie Ihren Feedback-Zyklus verkürzen. Wenn Sie z.B. nur eine Detektivregel haben, müssen Sie warten, bis alles in Betrieb genommen ist. Dann müssen Sie warten, bis ein Compliance-Problem auftaucht. Wenn Sie eine präventive Regel verwenden, können Sie dies auf verschiedenen Ebenen überprüfen:

1. Sie können die cfn-guard Regeln jederzeit in Ihrer lokalen Entwicklungsumgebung ausführen.
2. Sie können einen pre-commit Haken verwenden, der verhindert, dass Sie nicht konformen Code eingeben.
3. Sie können es während Ihres Continuous Integration-Schrittes ausführen. Dadurch wird verhindert, dass nicht konformer Code in Ihre Entwicklungs-/Hauptzweige eingebunden wird.
4. Sie können es vor der Bereitstellung für Tests, Abnahme und/oder Produktion ausführen.

Fazit

cfn-guard ist ein großartiges Werkzeug, um Compliance-Kontrollen sowohl für aufdeckende als auch für vorbeugende Kontrollen zu schreiben. Interessiert an einem Arbeitsbeispiel? Ich habe mein Demomaterial im GitHub-Repository Nr18/aws-meetup-2022-11-08 veröffentlicht.

Foto von Joshua Miranda