Skip to content

security.md

Latest commit

 

History

History
146 lines (80 loc) · 9.06 KB

security.md

File metadata and controls

146 lines (80 loc) · 9.06 KB
Raw

Security

Hardening the Installer Project

We originally used tfsec to scan this project for vulnerabilities. This has since been replaced by trivy due to tfsec's integration with the trivy project.

Terraform Scanning History

Patching vs Suppression vs Ignoring Reported Vulnerabilites

While it would be ideal to completely fix all reported issues, there are a few-complicating factors to be considered:

  • Testing vs Production

    Setting RDS config values like skip_final_snapshot = false and deletion_protection = true make absolute sense in a Production setting where it is highly unlikely one wants to destroy their database instance after it is created.

    These settings, however, interfere with the orderly spin-up/spin-down of resources created during a testing loop (i.e. terraform goes into an infinite loop waiting for a resource to be destroyed that cant be destroyed due actions taken by AWS as a result of these settings).

  • Uncertain cost implications due to cost of feature activation

    Some best practice features will generate real-world costs in your cloud account. While these costs are generally expected to be small, the fact that this cannot be 100% guaranteed from the outset means that these features should be treated as "opt-in" / "opt-out" rather than strictly hardcoded.

    Other features that do not have any additional cost by default can be hardcoded as true due to the zero-cost gains that are achieved.

    Example:

  • Uncertain Client Environments

    We cannot account for the realities of client environments and thus should not force hardcoded decisions upon them (e.g. forcing encryption of an EBS volume). Rather, we supply default values which align to best practices but allow the client to modify values, as necessary, to match the needs of their own environment.

  • Necessity of feature

    Some features, like configuring redis snapshot retention, arent necessary given how the Seqera Platform application works.

Mitigation approach

The following approach is being followed to mitigate vulnerabilities:

  1. Hardcode best practices where appropriate. Example: RDS Performance Insights (7-day retention).

  2. Use tfvars flags for toggle-able settings. Example: Make RDS deletion_protection configurable, with default set to true.

  3. Add checks to configuration checker to emit reminders/warnings.

  4. Suppress tfsec warnings for configurations handled by 2 & 3.

Tfsec suppressions in place

!!! warn "Trivy reporting errors on inner module config"

Some errors are being suppressed due to Trivy going too deep into module paths and reporting false positives (_i.e. multiple from the VPC examples folder_). Suppressing to minimize noise in scans to ensure real problems are not drowned out.

NOTE: I don't like using top-level overrides via `.trivyignore` but inline exceptions dont appear to be working.

Managed via .trivyignore:

Hardening Cloud Objects Created By The Project

We must balance security with convenience:

  • If the project is too strict on security, deployment efforts can be significantly slowed as a myriad of connectivity problems emerge and must be resolved.
  • Conversely, deployments with no security expose our clients to unnecessary risks which could have been easily mitigated with a few easy-to-make decisions.

We try to expose suggested best practices, but it ultimately the implementer's decision re: what is best for their organization. As you make this decision, please be mindful of the following items.

AMI Updating

By default, the installer will try to grab the very latest Amazon Linux 2023 AMI available in your region. This was modified in December 2024 (_see Make EBS boot volume configurable) where we maintained the core update logic but limited the AMI family type to al2023-ami-minimal- only.

This is generally seen as a good idea because it ensures security/application patches are introduced into your environment regularly. Unfortunately, it can occasionally cause VMs to be destroyed and replaced (potentially resulting in the loss of data if the implementation is using the container db) and can also knock highly regulated installations out of compliance (_i.e. if an AMI is auto-replaced without the necessary paperwork).

As of Release 1.3, more control has been introduced to allow implementers to pick a pattern which best fits their needs. Reference Issue

AMI & Package Patching

We use Amazon Inspector to scan the resulting EC2 for vulnerabilities. Vulnerabilities are tracked as Project Issues.

Egress Rules

Depending on the pipelines you run, many calls may need to egress from your Seqera Platform / Compute Environment to a variety of endpoints exposed on the public internet.

For ease of deployment, the installer starts from a very loose posture re: security egress controls (0.0.0.0/0). While this helps minimize stand-up efforts, it may be inappropriate for your eventual Production deployment stance. Please me mindful of this behaviour and lockdown as necessary once 'happy path' pipeline runs prove successful.