Add function to reverse-engineer CloudFormation templates and output the VaporShell script that recreates them.

[scrthq]

This has already been started on the feature/template-reconstructor branch, raising this issue for awareness as well as provide a place for those that are interested to subscribe to updates.

The goal with this new functionality is to aid in the adoption of VaporShell for those that are already established with other template building tools. It could also be leveraged as a helper tool for those that have an existing template that does what they are trying to build out in VaporShell as a way to see what a script would look like that contains the same resources/outputs/etc.

If this functionality is something you are interested in, subscribe to this issue for updates!

[RegEM]

Hi Nate,
To give some feedback, here is an example showing the format I am using for my roles/policies etc.. There probably is a better way, but it is making my manual conversion simpler for me to do.

$assumeRolePolicyDoc_ddbRole = `
'{
    "Version":"2012-10-17",
    "Statement":[{
        "Effect": "Allow",
        "Principal": {
            "Service": "iot.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
    }]
}' `
| ConvertFrom-JSON

( New-VSIAMRole -LogicalId "ddbRole" -AssumeRolePolicyDocument $assumeRolePolicyDoc_ddbRole ),

The formatting is off in this post. I have the json exactly as would be seen in the aws gui (indented), and some ticks as shown below for the powershell. Single quotes of course around the json.

$assumeRolePolicyDoc_ddbRole = `
'{
    "Version":"2012-10-17",
    "Statement":[{
        "Effect": "Allow",
        "Principal": {
            "Service": "iot.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
    }]
}' `
| ConvertFrom-JSON

[scrthq]

@RegEM so you shouldn't need to pipe it into ConvertFrom-Json, as the functions will be doing the same underneath the hood. Are you experiencing any differences when piping to ConvertFrom-JSON vs not? I tested both and the outputted object matched from what I can see using your examples. Other than that, I'm not sure what the feedback/issue is. Just looking for clarification so I know how to best use the feedback provided! 🥇 Feedback is greatly appreciated, always!

[RegEM]

Haha. Sure enough, right you are! I removed all my ConvertFrom-JSON lines without consequence . Plenty to learn... Thanks for the clarification.

I was struggling to convert my policies, and made mistake thinking I needed to do this. Not sure if there was an example.

In reality, I guess the feedback is that it can be a struggle to get this correct. And I was suggesting it would be nice if the output/conversion script that will be generated has the policies/permission elements in a recognizable format.

I imagine you have much of this mapped out already? But I don't know where your feature/template-reconstructor branch is? Mostly I am using dynamodb/lambda/s3,/iot, the events and logging for these and of course all the required permissions & policies.

[RegEM]

Hi Nate, Struggling to convert an IoT Topic Rule. Any help would great.

The 'path' in the sql is single quoted in the original yml. Which makes it tougher to declare. Simplified to "SELECT *" for time being.

DynodbRule: Type: AWS::IoT::TopicRule Properties: TopicRulePayload: RuleDisabled: false Sql: SELECT * FROM <path> Actions: - DynamoDB: TableName: sometbl HashKeyField: key HashKeyValue: ${key} RangeKeyField: eventTime RangeKeyValue: ${eventTime} PayloadField: Data RoleArn: !GetAtt 'ddbRole.Arn'

Tried Add-VSIoTTopicRuleDynamoDBAction, Add-VSIoTTopicRuleAction, New-VSIoTTopicRule, and currently loading a TopicRulePayload like this:

$IoTTopicRuleddBAction = Add-VSIoTTopicRuleDynamoDBAction
-HashKeyField "key" -HashKeyValue "${key}"
-RangeKeyField "eventTime" -RangeKeyValue "${eventTime}"
-PayloadField "Data" -RoleArn (Add-FnGetAtt -LogicalNameOfResource "ddbRole" -AttributeName "Arn")
-TableName "sometbl"

$VSIoTTopicRuleAction = Add-VSIoTTopicRuleAction -DynamoDB $IoTTopicRuleddBAction

$atopicRulePayloaddef = '{ "Actions": [ $VSIoTTopicRuleAction ], "RuleDisabled": False, "Sql": "SELECT *" }'

( New-VSIoTTopicRule -LogicalId "DynodbRule" -RuleName "topicRule1" -TopicRulePayloa $atopicRulePayloaddef )
`

The ddbRole was defined successfully.

[RegEM]

Figured it out, At least far enough along to say so.
Went back to some of what you showed me already. Thanks.

[scrthq]

Sweet! What was the fix? Apologies on the delay, busy weekend!

On Sun, Apr 1, 2018 at 3:29 PM RegEM ***@***.***> wrote: Figured it out, At least far enough along to say so. Went back to some of what you showed me already. Thanks. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMIo3T0XLTHY_Tvn4Tq_zpwEwA7VXZRqks5tkTiWgaJpZM4TAwQ-> .

-- Thank you for your time, Nate Ferrell (SCRT HQ)

[RegEM]

Fix was to create the Payload like this:

$atopicRulePayloaddef = @{
   Actions = @( $VSIoTTopicRuleAction )
   RuleDisabled = $False
   Sql = "SELECT * FROM 'folder/sub'"
}

(the technique you showed me earlier)

Re: revisiting the | ConvertFrom-JSON, I see when I removed it for one of my policies, the resulting Statement created by Add-VSIAMRolePolicy ends up as text in the yml file, instead of a list of statements.

Functionally I think they are the same, but visually it's not ideal.

With the | ConvertFrom-JSON removed, I get this,

PolicyDocument: "{\n    \"Version\": \"2012-10-17\",\n    \"Statement\"\
: [\n        {\n            \"Action\": [\n                \"logs:CreateLogGroup\"\
,\n                \"logs:CreateLogStream\",\n                \"logs:PutLogEvents\"\
\n            ],\n            \"Resource\": \"arn:aws:logs:us-east-1:edited:log-group:/aws/lambda/*:*:*\"\
,\n            \"Effect\": \"Allow\"\n        }\n    ]\n}"

Instead of this,

PolicyDocument:
  Version: '2012-10-17'
  Statement:
    - Action:
        - logs:CreateLogGroup
        - logs:CreateLogStream
        - logs:PutLogEvents
      Resource: arn:aws:logs:us-east-1:edited:log-group:/aws/lambda/*:*:*
      Effect: Allow

[scrthq]

Alright, you're correct on the odd conversion! I'll look into adding in logic for CloudFormation resource properties where the primitive type is JSON like the PolicyDocument type expects here: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-iam-policy.html

Going to open up a new issue for this to track separately!

[scrthq]

@RegEM check out issue #29 for updates on that! For now, please continue to pass a PSObject or Hashtable in as the value for the -PolicyDocument parameter with those IAM policy functions to workaround it.

[scrthq]

Testing webhook updates to Discord