feat(queries): new queries ECS Services assigned with public IP address for Ansible/aws, Terraform/aws and CloudFormation/AWS

[cx-ricardo-jesus]

Reason for Proposed Changes

• Currently there is no support for the verification of ECS Services being assigned with public IP addresses.

Proposed Changes

• To make this queries, I applied the same logic across all the platforms.
• According to the documentation of the platform's that this query is being implemented, the fields AssignPublicIp (CloudFormation), assign_public_ip(Terraform and Ansible) and the information present on the card, this fields should only be the cause of a vulnerability if it's defined and set to true on Ansible and Terraform and defined to ENABLED on CloudFormation, because by default these fields are defined to false/DISABLED.
• So, for all the platform's I only implemented the queries in order to return a positive result when the target field is defined to true or ENABLED.
• For ansible this verification on the query is made with the following line: ecs_service.network_configuration.assign_public_ip.
• For CloudFormation this verification is made with resource.Properties.NetworkConfiguration.AwsvpcConfiguration.AssignPublicIp == "ENABLED" .
• For Terraform, the verification is made with: resource.network_configuration.assign_public_ip
• For all the platforms I provided a sample (two samples on CloudFormation, one in json format and the other one in yaml format), that has the target field defined to true and ENABLED on CloudFormation.
• Also provided 3 negative samples for Terraform and Ansible queries, that as all the variations of the fields, two of them with the field's undefined and the other one with the field set to false which should not return a positive result.
• On the CloudFormation I provided four negative samples with two different cases, that are, one sample with the field defined to DISABLED and the other sample the field is not defined.

I submit this contribution under the Apache-2.0 license.

[github-actions]

KICS version: v2.1.11

Category Results CRITICAL 0 HIGH 0 MEDIUM 0 LOW 0 INFO 0 TRACE 0 TOTAL 0	Metric Values Files scanned 1 Files parsed 1 Files failed to scan 0 Total executed queries 47 Queries failed to execute 0 Execution time 0

[gitguardian]

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
4266022	Triggered	Generic Password	20e5fee	assets/queries/cloudFormation/aws/amplify_branch_basic_auth_config_password_exposed/test/negative7.yaml	View secret
9419039	Triggered	Username Password	20e5fee	assets/queries/cloudFormation/aws/amplify_branch_basic_auth_config_password_exposed/test/positive6.json	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[cx-eduardo-semanas]

LGTM