Restore release cadence

[Nuru]

what and why

• Reverts feat: use security-group module instead of resource #117, Updated with deployment circuit breaker #120, feat: add configurable runtime #151 to restore the ability to move forward on bug fixes and new features while maintaining backward compatibility
• Supersedes and closes set enable_ecs_service_role to true only if there is a load balancer #118, closes Unable to use module with bridge network_mode and without load balancers. #136, via Change condition for ecs_load_balancers #137, Fix Exception when no ALB is assigned to the service #145, thanks to @ragumix, @verbalius, @asiragusa
• Reimplements Updated with deployment circuit breaker #120 reverted above to maintain that functionality, closes Updated with deployment circuit breaker (#120) #122, thanks to @flywheelnz, @joe-niland
• Fixes external task_role and task_exec_role must exist before first run. #123
• Supersedes and closes Add task_definition_arn output #125, thanks to @nitrocode
• Supersedes and closes chore(deps): update terraform cloudposse/label/null to v0.25.0 #129, closes Update context.tf #130, closes chore(deps): update terraform cloudposse/security-group/aws to v0.4.0 #133
• Supersedes and closes fix ssm exec iam role #138, thanks to @mrsufgi
• Closes A managed resource "aws_security_group" "ecs_service" has not been declared in module.ecs_alb_service_task. #139, supersedes and closes A managed resource "aws_security_group" "ecs_service" has not been declared in module.ecs_alb_service_task. #140, thanks to @fentonfentonfenton
• Supersedes and closes Adds output for task exec role id #143, closes Expose uniqueid of task_exec role #142, thanks to @missylbytes
• Supersedes and closes fix: service-registeries optional fields #144, thanks to @mrsufgi
• Supersedes, implements, and closes feat: add configurable runtime #151, closes fix: Set AWS Provider Version Constraint to be >= 3.69.0 #152, thanks to @ethanrubio
• Supersedes and closes Chore: Run make github/init #154, thanks to @korenyoni

[bridgecrew]

Bridgecrew has found infrastructure configuration errors in this PR ⬇️

[bridgecrew]

  Ensure IAM policies does not allow write access without constraint
    Resource: aws_iam_policy_document.ecs_exec | ID: BC_AWS_IAM_57

How to Fix

           data "aws_iam_policy_document" "example" {
              statement {
                sid = "1"
                effect = "Allow"
                actions = [
                        "s3:*"
                ]
            
                resources = [
                  "foo",
                ]
              }
            }

Description

This policy allows actions that permit modification of resource-based policies or can otherwise can expose AWS resources to the public via similar actions that can lead to resource exposure.

For example:
1 - s3:PutBucketPolicy, s3:PutBucketAcl, and s3:PutObjectAcl grant permissions to modify the properties of S3 buckets or objects for new or existing objects in an S3 bucket, which could expose objects to rogue actors or to the internet.
2 - ecr:SetRepositoryPolicy could allow an attacker to exfiltrate container images (which sometimes unintentionally contain secrets and non-public information), tamper with container images, or otherwise modify.
3 - iam:UpdateAssumeRolePolicy could allow an attacker to create a backdoor by assuming a privileged role in the victim account from an external account.
The ability to modify AWS Resource Access Manager, which could allow a malicious actor to share a VPC hosting sensitive or internal services to rogue AWS accounts
Attackers can easily exploit Resource Exposure permissions to expose resources to rogue users or the internet, as shown by endgame, an AWS pentesting tool that was also released by Salesforce.

For more info, visit cloudsplaning documentation
https://cloudsplaining.readthedocs.io/en/latest/glossary/resource-exposure/

[bridgecrew]

  Ensure IAM policies do not allow data exfiltration
    Resource: aws_iam_policy_document.ecs_exec | ID: BC_AWS_IAM_55

How to Fix

        data "aws_iam_policy_document" "example" {
              statement {
                sid = "1"
                effect = "Allow"
                actions = [
                    "lambda:CreateFunction",
                    "lambda:CreateEventSourceMapping",
                    "dynamodb:CreateTable",
                ]
                resources = [
                  "*",
                ]
              }
            }

Description

Data Exfiltration actions allow certain read-only IAM actions without resource constraints, such as s3:GetObject, ssm:GetParameter*, or secretsmanager:GetSecretValue.

1 - Unrestricted s3:GetObject permissions has a long history of customer data leaks
2 - ssm:GetParameter* and secretsmanager:GetSecretValue are both used to access secrets.
3 - rds:CopyDBSnapshot and rds:CreateDBSnapshot can be used to exfiltrate RDS database contents.

For more info, visit cloudsplaning documentation
https://cloudsplaining.readthedocs.io/en/latest/glossary/data-exfiltration/

[bridgecrew]

  Ensure every Security Group rule has a description
    Resource: aws_security_group_rule.allow_all_egress | ID: BC_AWS_NETWORKING_31

Description

Descriptions can be up to 255 characters long and can be set and viewed from the AWS Management Console, AWS Command Line Interface (CLI), and the AWS APIs.

We recommend you add descriptive text to each of your Security Group Rules clarifying each rule's goals, this helps prevent developer errors.

Benchmarks

• SOC2 CC6.3.3
• ISO27001 A.10.1.1

[Nuru]

/test all

NOTE: Failure of Validate Codeowners is to due to restrictions placed on bots on this repository and is not significant.

[nitrocode]

LGTM

[korenyoni]

LGTM but left a comment

[korenyoni]

I believe this comes from a git revert, but I would leave this in