Merge branch 'master' into dependabot/pip/urllib3-1.26.18

.github/get_config_supported_resources.py

@@ -0,0 +1,78 @@
+import argparse
+from selenium import webdriver
+from selenium.webdriver.common.keys import Keys
+from selenium.webdriver.common.by import By
+from selenium.webdriver.chrome.options import Options
+from selenium.common.exceptions import NoSuchElementException
+import json
+import logging
+from concurrent import futures
+from collections import Counter
+import os
+import time
+import re
+import yaml
+
+"""
+Summary
+This is a simple web scraper to list the resource types supported by AWS Config.
+
+It will write its output to supported_resource_types.yaml -- this should be moved to the rdk subfolder after validating.
+"""
+
+all_resources = ["ALL"]  # Special string to support all resource types"]
+
+undocumented_but_supported = [
+    "AWS::EventSchemas::Registry",
+    "AWS::IoTTwinMaker::ComponentType",
+]
+
+all_resources += undocumented_but_supported
+
+url = "https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html"
+# Start the browser
+chrome_options = Options()
+chrome_options.add_argument("--headless=new")
+chrome_options.add_argument("--no-sandbox")
+chrome_options.add_experimental_option("excludeSwitches", ["enable-logging"])
+driver = webdriver.Chrome(
+    options=chrome_options,
+)
+
+# Open the login page
+driver.get(url)
+driver.implicitly_wait(2)
+
+# Iterate through every h2 header
+services = driver.find_elements(By.CLASS_NAME, "table-contents")
+
+# Walk through the table items
+for service in services:
+    if service.text == "":
+        continue
+    navigator = service
+    try:
+        # Find everything with a class of code and get its text
+        resources = navigator.find_elements(By.CLASS_NAME, "code")
+    except NoSuchElementException:
+        logging.info(f"No resources found for {service.text}")
+        continue
+    if len(resources) == 0:
+        logging.info(f"No resources found for {service.text}")
+        continue
+    # Assert that it matches "AWS::*"
+    for resource in resources:
+        if re.match(r"AWS::.*", resource.text):
+            # Remove any asterisks
+            resource_type = resource.text.replace("*", "")
+            # Add it to the output list
+            all_resources.append(resource_type)
+            logging.info(resource_type)
+
+driver.quit()
+
+# Return the output list, sorted
+yaml_output = {"supported_resources": sorted(list(set((all_resources))))}
+yaml_output_string = yaml.dump(yaml_output)
+with open("supported_resource_types.yaml", "w") as f:
+    f.write(yaml_output_string)

README.md

@@ -430,10 +430,10 @@ The above example would create files with config rule name as
 New as of version 0.3.11, it is possible to add RuleSet tags to rules
 that can be used to deploy and test groups of rules together. Rules can
 belong to multiple RuleSets, and RuleSet membership is stored only in
-the parameters.json metadata. The [deploy]{.title-ref},
-[create-rule-template]{.title-ref}, and [test-local]{.title-ref}
+the parameters.json metadata. The [deploy](docs/commands/deploy.md),
+[create-rule-template](docs/commands/create-rule-template.md), and [test-local](docs/commands/test-local.md)
 commands are RuleSet-aware such that a RuleSet can be passed in as the
-target instead of [--all]{.title-ref} or a specific named Rule.
+target instead of `--all` or a specific named Rule.
 
 A comma-delimited list of RuleSets can be added to a Rule when you
 create it (using the `--rulesets` flag), as part of a `modify` command,

developer_notes.md

@@ -38,6 +38,13 @@ These instructions document the parts of the repository that need to be updated
 To release a new version of RDK...
 
 1. Update `pyproject.toml` with the new version number
-2. Update `rdk/__init__.py`  with the new version number
+2. Update `rdk/__init__.py` with the new version number
 3. Locally `git pull origin master` to ensure you have the latest code
 4. Locally `git tag <new version number> && git push origin <new version number>` to create a tagged version, which will kick off the remaining workflows.
+
+## Running RDK from source
+
+1. Clone the RDK repo from git
+2. Make your changes
+3. `poetry build` # builds a wheel package inside of the dist folder
+4. `pip install --force-reinstall <path to your .whl file>` # optionally, use `--user` to install for just the current user.

docs/advanced-features/cross-Account-deployments.md

@@ -0,0 +1,58 @@
+# Cross-Account Deployments
+
+Features have been added to the RDK to facilitate the cross-account
+deployment pattern that enterprise customers have standardized for
+custom Config Rules. A cross-account architecture is one in which the
+Lambda functions are deployed to a single central "Compliance" account
+(which may be the same as a central "Security" account), and the
+Config Rules are deployed to any number of "Satellite" accounts that
+are used by other teams or departments. This gives the compliance team
+confidence that their rule logic cannot be tampered with and makes it
+much easier for them to modify rule logic without having to go through a
+complex deployment process to potentially hundreds of AWS accounts. The
+cross-account pattern uses two advanced RDK features:
+
+- `--functions-only` (`-f`) deployment
+- `create-rule-template` command
+
+## Functions-Only Deployment
+
+By using the `-f` or `--functions-only` flag on the `deploy` command the
+RDK will deploy only the necessary Lambda Functions, Lambda Execution
+Role, and Lambda Permissions to the account specified by the execution
+credentials. It accomplishes this by batching up all of the Lambda
+function CloudFormation snippets for the selected Rule(s) into a single
+dynamically generated template and deploy that CloudFormation template.
+One consequence of this is that subsequent deployments that specify a
+different set of rules for the same stack name will update that
+CloudFormation stack, and any Rules that were included in the first
+deployment but not in the second will be removed. You can use the
+`--stack-name` parameter to override the default CloudFormation stack
+name if you need to manage different subsets of your Lambda Functions
+independently. The intended usage is to deploy the functions for all of
+the Config rules in the Security/Compliance account, which can be done
+simply by using `rdk deploy -f --all` from your working directory.
+
+## create-rule-template command
+
+This command generates a CloudFormation template that defines the AWS
+Config rules themselves, along with the Config Role, Config data bucket,
+Configuration Recorder, and Delivery channel necessary for the Config
+rules to work in a satellite account. You must specify the file name for
+the generated template using the `--output-file` or
+`-o` command line flags. The generated template takes a
+single parameter of the AccountID of the central compliance account that
+contains the Lambda functions that will back your custom Config Rules.
+The generated template can be deployed in the desired satellite accounts
+through any of the means that you can deploy any other CloudFormation
+template, including the console, the CLI, as a CodePipeline task, or
+using StackSets. The `create-rule-template` command takes all of the
+standard arguments for selecting Rules to include in the generated
+template, including lists of individual Rule names, an `--all` flag, or
+using the RuleSets feature described below.
+
+```bash
+rdk create-rule-template -o remote-rule-template.json --all
+Generating CloudFormation template!
+CloudFormation template written to remote-rule-template.json
+```

docs/advanced-features/custom-lambda-name.md

@@ -0,0 +1,21 @@
+# Custom Lambda Function Name
+
+As of version 0.7.14, instead of defaulting the lambda function names to
+`RDK-Rule-Function-<RULE_NAME>` it is possible to customize the name for
+the Lambda function to any 64 characters string as per Lambda's naming
+standards using the optional `--custom-lambda-name` flag while
+performing `rdk create`. This opens up new features like :
+
+1. Longer config rule name.
+2. Custom lambda function naming as per personal or enterprise standards.
+
+```bash
+rdk create MyLongerRuleName --runtime python3.11 --resource-types AWS::EC2::Instance --custom-lambda-name custom-prefix-for-MyLongerRuleName
+Running create!
+Local Rule files created.
+```
+
+The above example would create files with config rule name as
+`MyLongerRuleName` and lambda function with the name
+`custom-prefix-for-MyLongerRuleName` instead of
+`RDK-Rule-Function-MyLongerRuleName`

docs/advanced-features/disable-resource-check.md

@@ -0,0 +1,13 @@
+# Disable the supported resource types check
+
+It is now possible to define a resource type that is not yet supported
+by rdk. To disable the supported resource check use the optional flag
+'--skip-supported-resource-check' during the create command.
+
+```bash
+rdk create MyRule --runtime python3.11 --resource-types AWS::New::ResourceType --skip-supported-resource-check
+'AWS::New::ResourceType' not found in list of accepted resource types.
+Skip-Supported-Resource-Check Flag set (--skip-supported-resource-check), ignoring missing resource type error.
+Running create!
+Local Rule files created.
+```

docs/advanced-features/generate-lambda-layer.md

@@ -0,0 +1,14 @@
+# Using RDK to Generate a Lambda Layer in a region (Python3)
+
+By default `rdk init --generate-lambda-layer` will generate an rdklib
+lambda layer while running init in whatever region it is run, to force
+re-generation of the layer, run `rdk init --generate-lambda-layer` again
+over a region
+
+To use this generated lambda layer, add the flag
+`--generated-lambda-layer` when running `rdk deploy`. For example:
+`rdk -f regions.yaml deploy LP3_TestRule_P39_lib --generated-lambda-layer`
+
+If you created layer with a custom name (by running
+`rdk init --custom-lambda-layer`, add a similar `custom-lambda-layer`
+flag when running deploy.

docs/advanced-features/managed-rules.md

@@ -0,0 +1,17 @@
+# Managed Rules
+
+The RDK is able to deploy AWS Managed Rules.
+
+To do so, create a rule using `rdk create` and provide a valid
+SourceIdentifier via the `--source-identifier` CLI option. The list of
+Managed Rules can be found
+[here](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html)
+, and note that the Identifier can be obtained by replacing the dashes
+with underscores and using all capitals (for example, the
+"guardduty-enabled-centralized" rule has the SourceIdentifier
+"GUARDDUTY_ENABLED_CENTRALIZED"). Just like custom Rules you will need
+to specify source events and/or a maximum evaluation frequency, and also
+pass in any Rule parameters. The resulting Rule directory will contain
+only the parameters.json file, but using `rdk deploy` or
+`rdk create-rule-template` can be used to deploy the Managed Rule like
+any other Custom Rule.

docs/advanced-features/multi-region-deployment.md

@@ -0,0 +1,12 @@
+# Deploying Rules Across Multiple Regions
+
+The RDK is able to run init/deploy/undeploy across multiple regions with
+a `rdk -f <region file> -t <region set>`
+
+If no region group is specified, rdk will deploy to the `default` region
+set.
+
+To create a sample starter region group, run `rdk create-region-set` to
+specify the filename, add the `-o <region set output file name>` this
+will create a region set with the following tests and regions
+`"default":["us-east-1","us-west-1","eu-north-1","ap-east-1"],"aws-cn-region-set":["cn-north-1","cn-northwest-1"]`

docs/advanced-features/rulesets.md

@@ -0,0 +1,48 @@
+# RuleSets
+
+New as of version 0.3.11, it is possible to add RuleSet tags to rules
+that can be used to deploy and test groups of rules together. Rules can
+belong to multiple RuleSets, and RuleSet membership is stored only in
+the parameters.json metadata. The [deploy](../commands/deploy.md),
+[create-rule-template](../commands/create-rule-template.md), and [test-local](../commands/test-local.md)
+commands are RuleSet-aware such that a RuleSet can be passed in as the
+target instead of `--all` or a specific named Rule.
+
+A comma-delimited list of RuleSets can be added to a Rule when you
+create it (using the `--rulesets` flag), as part of a `modify` command,
+or using new `ruleset` subcommands to add or remove individual rules
+from a RuleSet.
+
+Running `rdk rulesets list` will display a list of the RuleSets
+currently defined across all of the Rules in the working directory
+
+```bash
+rdk rulesets list
+RuleSets:  AnotherRuleSet MyNewSet
+```
+
+Naming a specific RuleSet will list all of the Rules that are part of
+that RuleSet.
+
+```bash
+rdk rulesets list AnotherRuleSet
+Rules in AnotherRuleSet :  RSTest
+```
+
+Rules can be added to or removed from RuleSets using the `add` and
+`remove` subcommands:
+
+```bash
+rdk rulesets add MyNewSet RSTest
+RSTest added to RuleSet MyNewSet
+
+rdk rulesets remove AnotherRuleSet RSTest
+RSTest removed from RuleSet AnotherRuleSet
+```
+
+RuleSets are a convenient way to maintain a single repository of Config
+Rules that may need to have subsets of them deployed to different
+environments. For example your development environment may contain some
+of the Rules that you run in Production but not all of them; RuleSets
+gives you a way to identify and selectively deploy the appropriate Rules
+to each environment.