Improve/clean terraform via snyk

[jbrown-xentity]

User Story

In order to have the most secure infrastructure, data.gov admin wants a complete review of the outstanding snyk vulnerabilities across the data.gov org and resolution via fixes, ignoring, or removing scans where appropriate.

Acceptance Criteria

[ACs should be clearly demoable/verifiable whenever possible. Try specifying them using BDD.]

• GIVEN 2 days have passed
  WHEN I look at the snyk dashboard
  THEN all terraform code registers as clean
  OR a specific issue is created to resolve the current state

Background

Discussed during pairing; we want to clean up the snyk dashboard and validate that our code is up to spec.
These have all been cleared and re-created to make sure they have the latest files/code.

Security Considerations (required)

Consult snyk dashboard for details.

Sketch

Examine the following projects in snyk, and any outstanding vulnerabilities. Please use pairing/review when appropriate; the goal of the snyk dashboard is to help us create secure infrastructure and use secure libraries in production. If something is being scanned that isn't relevant to that, then you can remove the scanning for that particular file (called "project" in snyk). See Dependency Scanning wiki for our details and best practices...

• eks-brokerpak
• datagov-iam
• datagov-ssb
• datagov-brokerpak-solr
• ...

[nickumia-reisys]

@GSA/data-gov-team This comment needs to be reviewed:

• https://app.snyk.io/org/data.gov/project/d52e37d3-b1a9-43c7-b3a9-48cc66ba6d05#issue-SNYK-CC-TF-116_resource.aws_iam_user_policy_attachment[ci]

If someone agrees with my assessment, we can ignore this permanently.

[nickumia-reisys]

@GSA/data-gov-team These comments are all the same to highlight the same problem that is repeated three times and needs to be reviewed:

• https://app.snyk.io/org/data.gov/project/3d6f6d77-e1d0-4d96-87da-69ae61d58af8#issue-SNYK-CC-TF-116_resource.aws_iam_user_policy_attachment[eks_broker_policies]
• https://app.snyk.io/org/data.gov/project/3d6f6d77-e1d0-4d96-87da-69ae61d58af8#issue-SNYK-CC-TF-116_resource.aws_iam_user_policy_attachment[smtp_broker_policies]
• https://app.snyk.io/org/data.gov/project/3d6f6d77-e1d0-4d96-87da-69ae61d58af8#issue-SNYK-CC-TF-116_resource.aws_iam_user_policy_attachment[solr_broker_policies]

If someone agrees with my assessment, we can "ignore" this permanently as "not vulnerable".

[jbrown-xentity]

Ignore those permanently, attaching to roles doesn't make sense in the context of a single automated user...

[nickumia-reisys]

The following issues have been made for the remainder of the snyk alerts:

• [datagov-ssb] KMS key does not have key rotation enabled #4095
• [terraform-kubernetes-aws-load-balancer-controller] Role with dangerous permissions  #4096
• [datagov-brokerpak-eks] 2048.yml vulnerabilities #4097
• [datagov-brokerpak-solr] SNS Topic Encryption #4100
• [datagov-brokerpak-solr] KMS key does not have key rotation enabled  #4101
• [datagov-brokerpak-solr] EFS in task definition does not encrypt data in transit  #4102
• [datagov-brokerpak-solr] ALB does not drop invalid headers  #4103
• [datagov-brokerpak-solr] Security Group allows open ingress/egress #4104
• [datagov-brokerpak-solr] CloudWatch log group not encrypted with managed key  #4105
• [datagov-brokerpak-solr] CloudWatch Log group retention period not set  #4106
• [datagov-brokerpak-solr] X-ray tracing is disabled for Lambda function  #4107

General process used to triage alerts:

• Determine if alert is a real vulnerability or a design choice
• If it is a design choice, ignore permanently with a detailed reason about the implementation details.
• If it is a vulnerability, open new issue and ignore temporarily for xx days (depending on our vulnerability timelines) to reassess the vulnerability at a later date.

[nickumia-reisys]

Other related efforts (for datagov-brokerpak-solr specifically):

• [Snyk] Security upgrade hashicorp/terraform from 1.1.5 to 1.3.4 GSA-TTS/datagov-brokerpak-solr#67
• Update go versions in cleanup script GSA-TTS/datagov-brokerpak-solr#68