CloudFormation टेम्पलेट्स के लिए लिंटिंग टूल
cfn-nag टूल CloudFormation टेम्पलेट्स में ऐसे पैटर्न खोजता है जो असुरक्षित इंफ्रास्ट्रक्चर का संकेत दे सकते हैं। मोटे तौर पर, यह निम्नलिखित की तलाश करेगा:
टूल के बारे में अधिक पृष्ठभूमि के लिए, कृपया Stelligent के ब्लॉग पर यह पोस्ट देखें:
यह मानते हुए कि Ruby >= 2.5.x इंस्टॉल है, इंस्टॉलेशन बस इतना करना है:
gem install cfn-nag
MacOS या Linux पर आप वैकल्पिक रूप से brew से इंस्टॉल कर सकते हैं:
brew install ruby brew-gem
brew gem install cfn-nag
CodePipeline में एक action के रूप में cfn_nag चलाने के लिए, आप AWS Serverless Application Repository के माध्यम से डिप्लॉय कर सकते हैं।
निष्पादित करने के लिए:
cfn_nag_scan --input-path <path to cloudformation json>
पथ एक डायरेक्टरी या कोई विशेष टेम्पलेट हो सकता है। यदि यह डायरेक्टरी है, तो सभी .json, .template, .yml और .yaml फ़ाइलें प्रोसेस की जाएंगी, जिसमें सबडायरेक्टरीज़ में रिकर्सिव रूप से जाना शामिल है।
डिफ़ॉल्ट आउटपुट प्रारूप फ्री-फॉर्म टेक्स्ट है, लेकिन --output-format json फ्लैग से json आउटपुट चुना जा सकता है।
वैकल्पिक रूप से, --debug फ्लैग रूल लोडिंग के आंतरिक विवरणों की जानकारी डंप करेगा।
समर्थित स्विचों की पूरी सूची के लिए --help के साथ चलाएँ।
cfn-nag वर्तमान में समर्थित सभी नियमों की सूची देखने के लिए, एक कमांड-लाइन उपयोगिता है जो उन्हें stdout पर डंप करेगी:
cfn_nag_rules
सुविधा के लिए एक Dockerfile प्रदान की गई है। यह 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 Workflow के भाग के रूप में चलाया जा सकता है।
अपनी GitHub Workflow फ़ाइल में, cfn_nag Action का उपयोग करने वाला एक step बनाएँ:
- name: Simple test
uses: stelligent/cfn_nag@master
with:
input_path: tests
GitHub Action के बारे में अधिक जानकारी यहाँ पाई जा सकती है।
cfn-nag 'profile' की अवधारणा का समर्थन करता है, जो प्रभावी रूप से लागू किए जाने वाले नियमों की अनुमति सूची (allow list) है। प्रोफ़ाइल एक टेक्स्ट फ़ाइल है जिसमें प्रति पंक्ति एक नियम पहचानकर्ता होना चाहिए। जब --profile-path कमांड लाइन तर्क के माध्यम से निर्दिष्ट किया जाता है, तो cfn-nag केवल उन विशेष नियमों से उल्लंघन लौटाएगा।
"profile" बनाने के पीछे की प्रेरणा यह है कि विभिन्न डेवलपर्स विभिन्न नियमों के बारे में चिंतित हो सकते हैं। उदाहरण के लिए, एक "infrastructure_developer" IAM नियमों की परवाह कर सकता है, जबकि एक "app_developer" IAM संसाधन भी नहीं बना सकता है और इसलिए उन नियमों की परवाह नहीं कर सकता है।
यहाँ एक उदाहरण प्रोफ़ाइल है:
F1
F2
F27
W3
W5
डिनाय सूची मूल रूप से प्रोफ़ाइल के विपरीत है: यह उन नियमों की सूची है जिन्हें कभी लागू नहीं करना है। जब --deny-list-path कमांड लाइन तर्क के माध्यम से निर्दिष्ट किया जाता है, तो cfn-nag फ़ाइल में निर्दिष्ट उन विशेष नियमों से कभी उल्लंघन नहीं लौटाएगा।
यदि कोई नियम दोनों में निर्दिष्ट है, तो डिनाय सूची प्रोफ़ाइल पर प्राथमिकता लेगी, और नियम लागू नहीं किया जाएगा।
प्रारूप निम्नलिखित है। केवल दो मुख्य फ़ील्ड हैं RulesToSuppress और प्रत्येक आइटम के लिए id। reason की व्याख्या cfn-nag द्वारा नहीं की जाएगी, लेकिन यह अनुशंसित है कि नियम को कभी लागू क्यों नहीं किया जाना चाहिए, इसका औचित्य और दस्तावेज़ीकरण किया जाए।
RulesToSuppress:
- id: W3
reason: W3 is something we never care about at enterprise X
यदि कोई ऐसा नियम है जिसे आप दबाना चाहते हैं, तो प्रभावित संसाधन में cfn_nag Metadata कुंजी जोड़ी जा सकती है ताकि cfn_nag को उस नियम के लिए विफलता या चेतावनी न बढ़ाने का निर्देश दिया जा सके।
उदाहरण के लिए, यदि आप एक सार्वजनिक-facing ELB सेट कर रहे हैं जो इंटरनेट से इनबाउंड कनेक्शन के लिए खुला है, जिसमें निम्नलिखित जैसे संसाधन हैं:
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::SecurityGroupIngress
cfn_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