Support for CloudFormation intrinsic functions (Go->YAML/JSON)

[PaulMaddox]

An alternative (to #103) implementation of CloudFormation references (!Ref).

It works by adding a few simple methods in the cloudformation package for inserting intrinsic functions, such as !Ref and !GetAtt. For example:

// Ref creates a CloudFormation Reference to another resource in the template
func Ref(logicalName string) string {
	i := `{ "Ref": "` + logicalName + `" }`
	return base64.StdEncoding.EncodeToString([]byte(i))
}

The following list of functions are available to use when creating templates:

• cloudformation.Ref(logicalName string)
• cloudformation.GetAtt(logicalName string, attribute string)
• cloudformation.ImportValue(name string)
• cloudformation.Base64(input string)
• cloudformation.CIDR(ipBlock, count, cidrBits string)
• cloudformation.FindInMap(mapName, topLevelKey, secondLevelKey string)
• cloudformation.GetAZs(region string)
• cloudformation.Join(delimiter string, values []string)
• cloudformation.Select(index string, list []string)
• cloudformation.Split(delimiter, source string)
• cloudformation.Sub(value string)

Example usage:

template := &cloudformation.Template{
	Resources: map[string]interface{}{
		"TestBucket": cloudformation.AWSS3Bucket{
			BucketName: "test-bucket",
		},
		"TestBucketPolicy": cloudformation.AWSS3BucketPolicy{
			Bucket: cloudformation.Ref("TestBucket"),
		},
	},
}

There is then a post-processor that replaces the any intrinsics represented as b64 strings, with a proper object, just before the template is marshalled to JSON or YAML.

Pros:

• No breaking API changes
• Nested intrinsics are supported
• Simpler API - consumers don't need to use cloudformation.NewString() and cloudformation.NewInteger() for every property
• Simpler overall implementation?

Cons:

• Intrinsic functions can only be placed in String fields, not Number fields

Fixes #12, #68, #90, #81, #31

[errordeveloper]

@PaulMaddox thanks for looking into this, I think it's definitely worse exploring!

I do see two additional limitations:

• nested intrinsics, few typical examples:
  • {"Fn::ImportValue": {"Fn::Sub": "${NetworkStackNameParameter}-SecurityGroupID"}}
  • {"Fn::Base64": {"Fn::Join": ["", ["something=", {"Ref": "Something"}]]}}
• parsing a template into a Go struct

Both of the above are actually important for eksctl use-case.

[PaulMaddox]

Parsing a template with intrinsics (inc. nested) into a Go struct will work. This should work already.

Nesting intrinsics should work when going from Go->YAML too (I'll add a test case for this).