DP-32110 maintenance calender as a generic module

[kayla-lcm]

This looks like kinda a lot but it's mostly the existing maintenance calendar module. It's been refactored a bit and gained a specific IAM role per task. Each task is also optional now, hence the submodules

[prisma-cloud-devsecops]

Prisma Cloud has found errors in this PR ⬇️

[prisma-cloud-devsecops]

  S3 lifecycle configuration does not set a period for aborting failed uploads
    Resource: aws_s3_bucket_lifecycle_configuration.maintenance_logs_lifecycle | Checkov ID: CKV_AWS_300

How to Fix

resource "aws_s3_bucket_lifecycle_configuration" "pass" {
  bucket = aws_s3_bucket.bucket.id

  rule {
+   abort_incomplete_multipart_upload {
+     days_after_initiation = 7
+   }
    filter {}
    id = "log"
    status = "Enabled"
  }
}

Description

This policy is verifying that there is a specified time period set for aborting failed uploads in the Amazon S3 lifecycle configuration. This is critical for preventing incomplete multipart uploads from consuming unnecessary storage, which could increase costs and potentially slow down system performance. If a multipart upload event fails, without a specified abort period, the partially uploaded data will continue to occupy space and accumulate associated charges.

[prisma-cloud-devsecops]

  Terraform module sources do not use a git url with a commit hash revision
    Resource: module.ecs_scans.ecs_cluster_image_scan | Checkov ID: CKV_TF_1

How to Fix

module "vpc" {
- source = "terraform-aws-modules/vpc/aws"
- version = "5.0.0"
+ source = "git::https://github.com/terraform-aws-modules/terraform-aws-vpc.git?ref=26c38a66f12e7c6c93b6a2ba127ad68981a48671"  # commit hash of version 5.0.0

  name = "my-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  enable_vpn_gateway = true

  tags = {
    Terraform = "true"
    Environment = "dev"
  }
}

Description

Terraform modules are a collection of multiple resource configuration to offer an easy way of repeatable and reusable code logic.
The most common way is to consume them through the public Terraform registry, which are connected to a VCS, like GitHub.
This approach is problematic, because the module versions are not immutable and the module can be changed without changing the version, which makes the code vulnerable to a Supply Chain Attack.
To mitigate this risk, it is recommended to use Git URLs with a commit hash revision to guarantee immutability and consistency. This is a more restrictive policy than https://docs.prismacloud.io/en/enterprise-edition/policy-reference/supply-chain-policies/terraform-policies/ensure-terraform-module-sources-use-git-url-with-commit-hash-revision[Terraform module sources do not use a git url with a tag or commit hash revision].

[jaredhm]

Is there an easy way to allow configuration of this list? It's kind of a pain in the ass to release updates to these terraform modules, and I'd imagine this list will grow as time goes on.

Maybe something like this?

const DEFAULT_IGNORE_SPECS = [
  {
    name: "CVE-2023-45853",
    packageName: "zlib",
    // ...
  }
];
const ignoreSpecs = process.env.IGNORE_SPECS_PARAMETER_ARN
  ? JSON.parse(await getSSMParameter(process.env.IGNORE_SPECS_PARAMETER_ARN))
  : DEFAULT_IGNORE_SPECS;
const getSSMParameter = async (parameter: string): Promise<string> => {
   const getParameterResult = await ssmClient.send(
     new GetParameterCommand({
       Name: parameter,
       WithDecryption: true,
     })
   );
  assert(getParameterResult?.Parameter?.Value);
  return getParameterResult.Parameter.Value;
}

[kayla-lcm]

Yeah I like that idea. This module needs the updated version of that lambda anyway. Probably a good time to do this too

[jaredhm]

if these are params are gonna be encrypted I have a hunch (tho could be wrong) that you'll also need to take the SSE key arn as a variable and grant kms:Decrypt on that.

[jaredhm]

If you do go down that road (I also think it'd be fine to just expect that the parameters are unencrypted), I'd recommend adding a policy condition along these lines:

"Condition": {
    "StringLike": {
        "kms:EncryptionContext:PARAMETER_ARN": [
          "${var.image_scan_ignore_arn}",
          "${var.image_scan_snooze_arn}"
        ]
    }
},

[jaredhm]

return isFindingIgnoredBySpecs(finding, ignored); is a bit more terse and probably no less clear

[jaredhm]

How would you feel about the snooze list being structured like this?

{
  cluster: string;
  snoozeUntil: string;
}

My thinking here is that 1) date is rather ambiguous as a property name and 2) the snooze ending at snoozeList.date + 7 days is a hidden behavior if you haven't read this code whereas snoozeList.snoozeUntil is immediately intelligible if you're poking around in parameter store

[jaredhm]

Also this is nitpicky as fuck but shouldn't it be called SnoozeListItem since the param is actually a list of these doohickeys?

[jaredhm]

May seem like overkill but timezones are the literal worst; maybe we could use something like js-joda to do this datetime math? My thinking is that you'd parse snooze.date as midnight UTC by default and then compare Date.now() - 7 days to that. Otherwise we're at the mercy at whatever Date.parse decides the default TZ is.