By using AWS re:Post, you agree to the Terms of Use

Questions tagged with AWS Config

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Lamdba to pull Cloudfront from AWS Config query

Hi, I am trying to use a lamdba to pull from multi accounts and grab CloudFront information, but the following aliases "cname" won't come back ``` selectExpression = "select accountId,resourceId,awsRegion,arn,resourceCreationTime,configurationItemStatus,configuration.domainName,configuration.lastModifiedTime,configuration.distributionConfig.aliases.items,configuration.distributionConfig.origins.items.customOriginConfig.*,configuration.distributionConfig.origins.items.customOriginConfig.httpPort,configuration.distributionConfig.origins.items.customOriginConfig.httpsPort,configuration.distributionConfig.origins.items.customOriginConfig.originSslProtocols,configuration.distributionConfig.origins.items.domainName" selectExpression = selectExpression + " where resourceType = 'AWS::CloudFront::Distribution' print(result['configuration']['distributionConfig']['aliases']['items']) ``` gets an error below but get origin works fine: ``` print(result['configuration']['distributionConfig']['origins']['items']) ``` Any suggestions? also in their docs: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-distributionconfig.html#cfn-cloudfront-distribution-distributionconfig-aliases and works with CLI ``` Error: Response { "errorMessage": "'Aliases'", "errorType": "KeyError", "requestId": "345fga5-a4f4-405b-8c43-319f750e6f1a", "stackTrace": [ " File \"/var/task/lambda_function.py\", line 62, in lambda_handler\n print(result['configuration']['distributionConfig']['Aliases']['items'])\n" ] } ``` ``` { "aliases": { "items": [ "www.foo.com" ] }, "origins": { "items": [ { "domainName": "awseb-e-j-AWSEBLA-1XXXXXXXXXX.us-east-2.elb.amazonaws.com", "customOriginConfig": { "originSslProtocols": { "quantity": 3, "items": [ "TLSv1.2" ] }, "httpPort": 80, "httpsPort": 443 } } ] } } ```
1
answers
0
votes
21
views
asked a day ago

AWS Config Gard Rule Evaluation

Hello folks I am having a hard time understanding how AWS guard rules that fail and pass are evaluated when used with Config. I wanted to replicate an existing rule that detects public S3 buckets: https://github.com/aws-cloudformation/cloudformation-guard/blob/901d40a6f01553d14adf9ab398c7eec55c2b5a36/guard/resources/rules-dir/s3_bucket_public_read_prohibited.guard I realized that this rule applies to a cloudformation template. I wanted to apply it to a Config recorded object so i adapted the rule to: ``` rule isPublicAccessBlockConfigurationBlockSecure when isPublicAccessBlockConfigurationBlockPresent { supplementaryConfiguration.PublicAccessBlockConfiguration exists supplementaryConfiguration.PublicAccessBlockConfiguration.blockPublicAcls == true supplementaryConfiguration.PublicAccessBlockConfiguration.blockPublicPolicy == true supplementaryConfiguration.PublicAccessBlockConfiguration.ignorePublicAcls == true supplementaryConfiguration.PublicAccessBlockConfiguration.restrictPublicBuckets == true } ``` When testing this locally (cfn-guard) i got a fail on an open bucket with an explanation along the lines: ``` Property traversed until [/supplementaryConfiguration] in data [PublicBucketAccess-test-fail.json] is not compliant with [PublicBucketAccess.guard/absentPublicAccessBlockConfigurationBlock] due to retrieval error. ``` I was under the assumption that if there is a retrieval error, Config marks the resource as non-compliant but it either provides no results or marks it as compliant and does not give any error. However, when i changed to: ``` rule isBucketToBeSecured when resourceType == "AWS::S3::Bucket" { ...some checks... } rule isPublicAccessBlockConfigurationBlockPresent when isBucketToBeSecured { supplementaryConfiguration.PublicAccessBlockConfiguration exists } rule isPublicAccessBlockConfigurationBlockSecure when isPublicAccessBlockConfigurationBlockPresent { supplementaryConfiguration.PublicAccessBlockConfiguration.blockPublicAcls == true supplementaryConfiguration.PublicAccessBlockConfiguration.blockPublicPolicy == true supplementaryConfiguration.PublicAccessBlockConfiguration.ignorePublicAcls == true supplementaryConfiguration.PublicAccessBlockConfiguration.restrictPublicBuckets == true } ``` It now works. Does anyone know why Config has such a strange evaluation mechanism where a failure to retrieve a key gives no compliance results or marks the resources as good to go? Also, is there a cleaner way to test for the existence of a key before trying to access subkeys without causing a failure. When i used: ``` rule taggedBucketIsSecure2 when resourceType == "AWS::S3::Bucket" { let publicAccessBlockConfiguration = supplementaryConfiguration.PublicAccessBlockConfiguration when %publicAccessBlockConfiguration exists { supplementaryConfiguration.PublicAccessBlockConfiguration.blockPublicAcls == true supplementaryConfiguration.PublicAccessBlockConfiguration.blockPublicPolicy == true supplementaryConfiguration.PublicAccessBlockConfiguration.ignorePublicAcls == true supplementaryConfiguration.PublicAccessBlockConfiguration.restrictPublicBuckets == true } } ``` I got: ``` Rule [PublicBucketAccess.guard/taggedBucketIsSecure2] is not applicable for template [PublicBucketAccess-test-fail.json] ``` I assume the problem is that since when does not evaluate to true, it skips the evaluation and instead of marking the resource as non-compliant it either fails or marks it as compliant. Thanks in advance
0
answers
0
votes
21
views
asked a month ago

AWS Control Tower 3.0 creates two Config Aggregators - why?

I created a new organization using AWS Control Tower (version 3.0). It seems that it has created two aggregators: * An accounts aggregator under the audit account named control `aws-controltower-GuardrailsComplianceAggregator`. This aggregator is defined to collect from specific accounts (all member accounts, excluding the management account), and from all regions. However, at least in my case, the authorizations given from these accounts to aggregation seem messed up - each account was only set up to authorize aggregation from 5 regions, and the aggregator indeed identifies the aggregation from some accounts and regions as failed as a result. FYI, I currently created my control tower landing zone on a single region, not sure why this setup happened. * An organization aggregator in the management account named `aws-controltower-ConfigAggregatorForOrganizations`. This organization aggregator automatically collects from all accounts and regions in the organization, and it is working well. Any idea why both aggregators were defined? I know that until a recent version of the landing zone, there was no support for organization aggregators. But now that it has been added, why keep the account-specific aggregator in the audit account (that seems to be misconfigured anyway)? On the flip side, given that the best practice is to use the audit account for, well, auditing - why is the organization aggregator defined on the management account and not the audit account? Doesn't that mean that to enjoy its aggregation I need to login to the management account? Thanks,
0
answers
0
votes
38
views
asked 2 months ago