cfn_nag
v0.8.10
CFN-NAGツールは、不安定なインフラストラクチャを示す可能性のあるCloudFormationテンプレートのパターンを探します。大まかに言えば、それは探します：
ツールの詳細については、Stelligentのブログのこの投稿をご覧ください。
「CFN-NAG」を使用したクラウドフォーム化テンプレートの開発プロセスの初期のセキュリティ問題を見つける
Ruby> = 2.5.xがインストールされていると仮定します。インストールは次の問題です。
gem install cfn-nagMacosまたはLinuxでは、brewでインストールできます。
brew install ruby brew-gem
brew gem install cfn-nag CODEPIPELINEでのアクションとしてcfn_nagを実行するには、AWS ServerLessアプリケーションリポジトリを介して展開できます。
実行する：
cfn_nag_scan --input-path < path to cloudformation json >パスは、ディレクトリまたは特定のテンプレートにすることができます。ディレクトリの場合、すべての.json, .template 、 .yml 、および.yamlファイルが処理されます。
デフォルトの出力形式はフリーフォームテキストですが、JSON出力は--output-format jsonフラグで選択できます。
オプションで、 --debugフラグは、ルールロードの内部に関する情報をダンプします。
サポートされているスイッチの完全なリストのために--helpで実行します。
CFN-NAGが現在サポートしているすべてのルールのリストを表示するには、それらをstdoutにダンプするコマンドラインユーティリティがあります。
cfn_nag_rulesDockerFileは便利なために提供されます。 dockerhubでstelligent/cfn_nagとして公開されています。
https://hub.docker.com/r/stelligent/cfn_nag
ローカルで構築することもできます。
docker build -t stelligent/cfn_nag .テンプレートを含むローカルディレクトリをDockerコンテナにマウントし、コンテナ内のCFN_NAGを呼び出すことができます。この例では、CFN_NAGの単体テストで使用されるテストテンプレートを使用しています。
$ 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 、GitHubワークフローの一部として実行して、継続的な統合パイプライン中にコードを評価できます。
GitHubワークフローファイルで、CFN_NAGアクションを使用するステップを作成します。
- name : Simple test
uses : stelligent/cfn_nag@master
with :
input_path : testsGitHubアクションの詳細については、こちらをご覧ください。
CFN-NAGは、「プロファイル」の概念をサポートしています。これは、事実上、適用されるルールのリストを許可することです。プロファイルは、行ごとのルール識別子を含む必要があるテキストファイルです。 --profile-pathコマンドライン引数を介して指定された場合、CFN-NAGはこれらの特定のルールから違反のみを返します。
「プロファイル」を作成する背後にある動機は、さまざまな開発者が異なるルールを気にかける可能性があることです。たとえば、「Infrastructure_Developer」はIAMルールを気にする場合がありますが、「app_developer」はIAMリソースを作成することさえできず、したがってそれらのルールを気にしない場合があります。
これがプロファイルの例です。
F1
F2
F27
W3
W5
拒否リストは基本的にプロファイルの反対です。これは、適用されないルールのリストです。 --deny-list-pathコマンドライン引数を介して指定された場合、CFN-NAGは、ファイルで指定された特定のルールから違反を返すことはありません。
両方でルールが指定されている場合、拒否リストはプロファイルよりも優先され、ルールは適用されません。
フォーマットは次のとおりです。唯一の2つの顕著なフィールドは、 RulesToSuppressとアイテムあたりのidです。そのreason CFN-NAGによって解釈されることはありませんが、ルールを決して適用しない理由を正当化して文書化することをお勧めします。
RulesToSuppress :
- id : W3
reason : W3 is something we never care about at enterprise X抑制したいルールがある場合、 cfn_nag Metadataキーを影響を受けるリソースに追加して、CFN_NAGにそのルールの障害または警告を発生させないように指示できます。
たとえば、以下のようなリソースを使用して、インターネットからインバウンド接続に開かれている公共の肘を設定している場合：
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は、次のような警告を提起します。
$ 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: 2メタデータを追加することにより、これらの警告を抑制することができます。
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テンプレートパラメーターは、展開ポイントで値が指定されているため、静的分析の問題を提示できます。言い換えれば、静的分析が完了した場合、値は使用できません。静的分析は、その前にある「コード」のみを見ることができます。したがって、CIDRがパラメーター化され、0.0.0.0/0が展開時に渡された場合、0.0.0.0/0のセキュリティグループのイングレスルールはフラグが付けられません。
パラメーター値を確認するために、ユーザーは、 cfn_nagとcfn_nag_scanの両方にコマンドラインに渡されたJSONファイルのパラメーター値を--parameter-values-path=<filename/uri>フラグを指定できます。
JSONの形式は単一のキー「パラメーター」であり、その値は各キー/値ペアのマッピングをパラメーターにマッピングする辞書です。
{
"Parameters" : {
"Cidr" : " 0.0.0.0/0 "
}
}これにより、次のパラメーターに「0.0.0.0/0」が提供されます。
Parameters :
Cidr :
Type : String JSONに追加のパラメーターがある場合、それらは静かに無視されていることに注意してください（ cfn_nag_scanすべてのテンプレートに同じJSONを適用できるようにするため）。
JSONが奇形であるか、上記の仕様を満たしていない場合、解析は致命的な違反で失敗します。
0.5.55の前に、FN :: findInMapへの呼び出しは効果的に無視されました。基礎となるモデルはそれらを残すため、ルールのハッシュ値として表示されます。例： { "Fn::FindInMap" => [map1, key1, key2]}
0.5.55から、モデルは、FindInMapの呼び出しの値を計算し、ルールにその値を提示しようとします。この評価は、次のキーをサポートしています。
評価ロジックがキーの値を把握できない場合、式全体に対してハッシュを返すという古い動作にデフォルトになります。
また、0.5.55の前に、AWSの擬似ファンクションへの呼び出しは効果的に無視されました。基礎となるモデルはそれらを残すため、ルールのハッシュ値として表示されます。例： {"Ref"=>"AWS::Region"} 。一般的なユースケースは、地域ごとにマッピングを整理することです。そのため、マップ評価をよりよくサポートするためには、擬似機能評価が重要です。
0.5.55から、モデルは、デフォルト値を使用して、次のAWSの違いをルールに提示します。
'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'
さらに、エンドユーザーは、従来のパラメーター置換メカニズムを介して提供される値をオーバーライドできます。例えば：
{
"Parameters" : {
"AWS::Region" : " eu-west-1 "
}
}CFN_NAGのバージョン0.4.66まで、基礎となるモデルは、テンプレート内でFN ::の処理を行いませんでした。これは、プロパティが条件付き値を持っている場合、FN :: ifを解析するのは規則次第であったことを意味します。 FN ::はどこにでも表示される可能性がある場合、ルール開発者に馬車の状況が生まれました。せいぜい、ルールロジックは、そもそも値をハッシュと仮定した値である値を無視する可能性があります。
この問題に対処するために、CFN_NAGのデフォルトの動作は、真の結果を使用してFN ::を置き換えることになります。これは、デフォルトでは、ルールがセキュリティ違反の虚偽の結果を検査しないことを意味します。
FN ::の置換に加えて、プロパティ値レベルでの場合、同じ動作がFN ::の場合、プロパティのトップレベルに適用されます。例えば：
Resource1 :
Type : Foo
Properties : !If
- IsNone
- Description : Up
- Description : DOwn同じように見えます：
Resource1 :
Type : Foo
Properties :
Description : Upこの動作をある程度制御するために、ユーザーは、 cfn_nagとcfn_nag_scanの両方にコマンドラインで渡されたJSONファイルの条件値を指定し--condition-values-path=<filename/uri>フラグを指定できます。
JSONの形式は、各キー/値ペアのマッピングを条件に伴うAA辞書です。
{
"Condition1" : true ,
"Condition2" : false
}SPCMの基礎は、IAMポリシードキュメントの複雑さを提案したブログ投稿思考実験で説明されています。
CFN_NAGのバージョン0.6.0から始まります：
spcm_scan CloudFormationテンプレートのディレクトリ（CFN_NAG_SCANなど）をスキャンし、JSONまたはHTML形式のSPCMメトリックを含むレポートを生成できますcfn_nag_scan --rule-arguments spcm_threshold:100--rule-argumentsメカニズムを介して設定のエンドユーザー値を受け入れるルールを開発できるようになりました。 --rule-argumentsオブジェクトは、 attr_accessorを宣言する必要がありますattr_accessor :spcm_threshold0.5.xのリリースには、カスタムルール（CAN）の分布とロードのいくつかの大きな変更が含まれます。このリリースの前に、コアCFN_NAG GEM内のlib/cfn-nag/custom_rulesディレクトリと、コマンドラインで指定されたカスタムルールディレクトリの2つの場所がロードされました。
カスタムルールがロードされている方法/場所の再設計を強制する2つのユースケースがあります。ルールの読み込みメカニズムは、カスタムルールリポジトリを使用してルールを発見できるように一般化されています。
ファイルシステムに座っている「ルールファイル」の束は、従来のソフトウェア開発の観点からはあまり大きくありません。これらのファイルにバージョンやトレーサビリティはないため、0.5.xは「CFN_NAGルールGEM」の概念を導入します。開発者は、個別のGEMの一部としてカスタムルールを開発し、バージョンITとインストールできます。これらのルールは、GEMメタデータにcfn_nag_rules => true含まれている限り、CFN_NAGから参照されます。 「cfn-nag-hipaa-rule」のような名前の宝石の場合、lib/cfn-nag-hipaa-rulesの下の *.rbがロードされます。カスタムルールは、CFN-Nag/base_ruleのCFNNAG :: Baserule（CFN-Nag/Custom-Rule/Baseではない）から派生する必要があります。ルールが他の何かに由来する必要がある場合、メソッドcfn_nag_rule?それが真の返品は、それが原則としてロードされる原因になります。
CFN_NAGがAWS Lambdaで実行されている場合、従来の意味では実際にファイルシステム（ /TMP以外）はありません。したがって、ラムダから使用可能なコアルールのみが使用されます。カスタムルールをサポートするために、CFN_NAGはファイルシステムの代わりにS3バケットからルールの発見をサポートしています。
Rubyでカスタムルールを開発する方法について見た可能性が高いことはすべて、まだ当てはまります。
S3バケットからルールを見つけるには、このコンテンツでファイルs3.ymlを作成します。
---
repo_class_name : S3BucketBasedRuleRepo
repo_arguments :
s3_bucket_name : cfn-nag-rules-my-enterprise
prefix : /rulesBucket CFN-Nag-rules-my-enterpriseをプレフィックス /ルール（ /rules/mynewrule.rb）に適用するには、コマンドラインのこのファイルをCFN_NAGに指定します。
cat my_cfn_template.yml | cfn_nag --rule-repository s3.ymlルールが複数のバケットにある場合は、複数のs3*.ymlファイルを作成し、 --rule-repository引数でそれらを指定します。
Ambient AWS資格情報がBucket cfn-nag-rules-enterpriseにアクセスする許可を持つ場合、 /rules/*Rule.rbのようなすべてのルールが見つかります。特定のAWS_PROFILEを使用する必要がある場合は、 repo_argumentsの下でキーとして追加しますaws_profile: my_aws_profile
ファイルシステムを超えて、GEMはインストールし、S3-新しいアーキテクチャは、DynamoDB、リレーショナルデータベース、またはその他のWebサービスからルールをロードするために、他の「ルールリポジトリ」の開発を理論的にサポートしています。
独自の使用および/またはコミュニティの貢献に関する新しいルールを執筆するには、詳細についてはカスタムルール開発を参照してください。
スープからナッツへのTDDカスタムルール開発を示すスクリーンキャストはこちらから入手できます。
https://www.youtube.com/watch?v=jrzct0nafd4&t=1601S
仕様を実行するには、Dockerがインストールされ、CFN_NAG依存関係がインストールされていることを確認する必要があります。
gem install bundle
bundle install次に、すべての仕様を実行するには、 rake test:allを実行するだけです。
エンドツーエンドテストを実行するには、 rake test:e2e 。スクリプトは、GEMFILEのすべての宝石をバンドルし、CFN_NAG GEMをローカルにビルドしてインストールし、仕様依存関係をインストールし、「END_TO_END」でタグ付けされたテストを実行します。また、Amazonが提供するサンプルテンプレートを引き下げ、CFN_NAG_SCANに対して実行して、CFN-NAG内の例外を引き起こすかどうかを確認します。
現在のgitブランチをローカルにインストールするには：
bundle install
scripts/deploy_local.shルールの開発と作成を容易にするために事前に構成されたすべてのツールと設定を備えた完全なリモート開発環境が作成およびセットアップされています。 VSコードリモート開発機能を使用して、これを有効にできます。
Folder contains a dev container configuration file. Reopen folder to develop in a container Reopen in Containerクリックします[Dev Container] cfn_nag Developmentオプションを使用しますVSコードリモート開発セットアップの詳細については、VSコードリモート開発をご覧ください。
バグを報告するか、機能をリクエストするには、https：//github.com/stelligent/cfn_nag/issues/newでgithubリポジトリから問題を送信します
