Enhance ELB with Ingress and IP-Whitelist Filters

[dschro-1993]

Hey Guys :)

We had a requirement to perform some more advanced Filters on Security Groups and/or WebACLs attached to ELBs.
Currently, the functionality in C7n for this is quite limited.

• For Security Groups there is only a common Value-Filter to check certain attributes from describe-call via limited JMESPath queries.

Example:

policies:
- name:      app-elb-test
   resource: app-elb
   filters:
   # What is missing is a Range-Check for example:
   # Compare inbound rules in SG vs what is whitelisted in external sources => Example below
   - type:  security-group
     value: ["0.0.0.0/0", "::/0"]
     key:   "IpPermissions[].IpRanges[].CidrIp"
     op:    contains

• For WAFs/WebACLs there is only a Value-Filter to check mostly Association/Attachment.

Example:

policies:
- name:      app-elb-test
   resource: app-elb
   filters:
   - type:  wafv2-enabled
     state: false

Within my Pull Request I have added the Ingress-Filter from the Security Group to the ELB Resources, so that it can be used directly here with all its Features.
Plus, I have added a new WAFv2-Filter that performs a deep rule introspection to check for any IPSetStatements and proper IP-Whitelist functionality on ALBs (based on customer needs).

Example:

policies:
- name:      app-elb-test
   resource: app-elb
   filters:
    - type: ingress
      Cidr:
        value_type: cidr
        value_from:
          url:    s3://<Your-Bucket>/<Whitelisted-Cidrs>.txt
          format: txt
        op: ni
      - type: wafv2-ip-whitelisting
        enabled: False # => Means: No WebACL associated or no IPSets attached or they allow more than what is whitelisted
        whitelist_from:
          url:    s3://<Your-Bucket>/<Whitelisted-Cidrs>.txt
          format: txt

Please let me know if you think it would be a nice contribution to the ELB Resources and whether you want to improve/adjust certain parts.

[kapilt]

I do wonder if we can be more efficient about this, either by leveraging the existing security group filter or directly fetching from the resource manager. the existing security group filters do seem like they would be useful since they contain the metadata for different resource types. ie. I think ingress/egress might be something we can expose generically across all network attached resources if they have an extant security group filter.

at the moment, if I have a 100 load balancers, with the same security group attached to them all, this will do a 100 api calls, even though one would have sufficed.

[kapilt]

put up a separate pr to cover the ingress/egress more generically #9382 and reuse extant security group filters.