Support lists in configuration

[mcbanderson]

We currently only support regular key-value pairs, and map/dict values. We should support list values as well.

How to reproduce: reflex.yaml

rules:
  aws:
  - my-rule:
      configuration:
        foo:
          - bar
          - baz
      version: latest

reflex build

Expected output: my-rule.tf

module "my-rule" {
  source            = "git::https://github.com/cloudmitigator/my-rule.git?ref=latest"
  sns_topic_arn     = module.central-sns-topic.arn
  reflex_kms_key_id = module.reflex-kms-key.key_id
  foo = [
    "bar",
    "baz",
  ]
}

Actual output: my-rule.tf

module "my-rule" {
  source            = "git::https://github.com/cloudmitigator/my-rule.git?ref=latest"
  sns_topic_arn     = module.central-sns-topic.arn
  reflex_kms_key_id = module.reflex-kms-key.key_id
  foo = ['bar', 'baz']
}

[rjulian]

Should we wait to support this until we see a need for list-type configurations? I can't, with our current infrastructure, think of a time we'd need list-type options.

[mcbanderson]

I actually see a pretty immediate need for it. The cloudfront-viewer-tls-protocol rule currently hard codes the list of allowed protocol versions (https://github.com/cloudmitigator/reflex-aws-cloudfront-viewer-tls-protocol/blob/master/source/reflex_aws_cloudfront_viewier_tls_protocol.py#L25), but this really should be configurable. And a list configuration makes the most sense to me.

Adding support to the CLI is going to be trivial, what we'll probably need to put some thought into is how the lists get injected into environment variables. (I suspect we'll need to do a json string that then gets parsed.)

[rjulian]

So, I saw that there would eventually be the case where we have to inject multiple values into env variables. I think the simplest solution right now is what we'd have to do no matter what using environment variables: comma separated lists. Essentially: ami_id: ami-069494,ami-069999 and then have the lambda split into the list.

Even if we provide the CLI support for putting them as a yaml list under the config item, we'll still have to somehow transfer that to a comma separated string if the ultimate goal is to inject them as env vars to the lambda. Additionally, I don't think it'll be intuitive to end users that the yaml array format is our desired format. I will admit that it's far cleaner looking to do a yaml list.