Support private HTTP template URLs

[jpb]

Use signed URL for http/https Templates to support non-public readable templates hosted on S3.

[ghost]

lgtm

[tavisrudd]

What happens if the location is already a signed s3 url (possibly from a different account)?

[jpb]

From what I can tell, S3 doesn't support signature v2 which has a maximum one year expiry. Signature v4 has a maximum 7 day expiry. Given that signed URLs have such a short lifetime, I don't think this is an edge case we need to support right now. I think a better solution would be to give the current IAM principal access to the other account's bucket or just use a bucket in the same account.

[tavisrudd]

Regardless of the expiration issue, I think we need to respect that other tooling might be passing one in. A check for Signature= in the location would suffice to handle that case.

[tavisrudd]

I think we should also add a comment explaining why we're checking / rewriting the URL here and how this use case is different from the s3://... url rewrite that this function does on lines 601-608.

[garbles]

Seems good

[jpb]

It looks like this introduced a bug for rendered templates - Template: render:stack.yaml produces the error:

error: Your cloudformation Template from stack.yaml appears to use iidy's yaml pre-processor syntax.
 You need to prefix the template location with "render:".
 e.g.   Template: "render:stack.yaml"