RFD - GitLab SAST scans report critical & high vulnerabilities for Nebari in AWS

[joneszc]

Status	Draft 🚧 / Open for comments 💬
Author(s)	@joneszc
Date Created	05-09-2024
Date Last updated	dd-MM-YYY
Decision deadline	N/A

Title

SAST Scans Show Nebari Has Critical/High Vulnerabilities in AWS

Summary

Of the several critical vulnerabilities reported by GitLab SAST for Nebari, deployed in AWS, some vulnerabilities could be mitigated by adding AWS Key Management Service (KMS) controls & configuration options in addition to applying encryption as default settings in the corresponding AWS services:

• CRITICAL: EKS Cluster Encryption Disabled
• CRITICAL: Aurora With Disabled at Rest Encryption
• CRITICAL: KMS Key With Vulnerable Policy (nebari-mlflow-aws)
• CRITICAL: DynamoDB Table Not Encrypted
• CRITICAL: KMS Key With Vulnerable Policy (terraform-state)
• CRITICAL: KMS Key With Vulnerable Policy (s3)

User benefit

Defense in Depth Security Strategy

Design Proposal

MITIGATION:

• CRITICAL: EKS Cluster Encryption Disabled
  - Add encryption_config to aws_eks_cluster tf resource that enables a config option to accept an ARN of a KMS key
  - Proposing PR#2723 as solution
• CRITICAL: Aurora With Disabled at Rest Encryption
  - Add storage_encrypted into the aws_rds_cluster tf resource and set as true
• CRITICAL: KMS Key With Vulnerable Policy (nebari-mlflow-aws)
  - Possibly add either a kms_key policy or a separate kms_key_policy resource
• CRITICAL: DynamoDB Table Not Encrypted
  - Consider adding server_side_encryption into the aws_dynamodb_table resource and setting enabled: true as default with optional config variable for kms_key_arn
• CRITICAL: KMS Key With Vulnerable Policy (terraform-state)
  - Possibly add either a kms_key policy or a separate kms_key_policy resource
• CRITICAL: KMS Key With Vulnerable Policy (s3)
  - Possibly add either a kms_key policy or a separate kms_key_policy resource

Alternatives or approaches considered (if any)

Best practices

User impact

Unresolved questions