Skip to content

Latest commit

 

History

History
50 lines (38 loc) · 2.36 KB

v0.12.md

File metadata and controls

50 lines (38 loc) · 2.36 KB

Announcement for v0.12

We are happy to announce a major upgrade to the Farge service module to v0.12. This upgrade brings compliance with major compliance frameworks: CIS AWS V1.3, PCI-DSS V3.2, NIST-800-53, ISO27001, and SOC2. Additionally, we have updated our publishing process to prevent changes to the module that would violate any of these compliance frameworks.

Release Notes

We made several upgrades to this module. Read further to assess any risk to upgrading your services.

  • Enabled in-transit encryption for EFS volumes.
  • Using CMK (customer-managed key) when encrypting cloudwatch logs, secrets, and image repository.
  • Enabled image scanning when an image is pushed to the image repository.
  • Enabled tag immutability on the image repository. Can only push an image once.

Upgrading

This upgrade will cause a redeployment of the service. While this will not cause downtime, it will cause a new deployment that repeatedly fails. You will need to redeploy your service immediately after the upgrade. See "Image Repository" section below for more details.

Database Access

We released the RDS Postgres module at the same time. Do not perform this upgrade while upgrading an attached RDS Postgres.

Image Repository

This upgrade enables encryption of your docker images. This requires destroying and recreating your image repository containing your docker images. As a result of this upgrade, your image repository will be empty.

Your existing services will be unaffected, but any service restarts or redeploys will fail because the image no longer exists. To avoid this, build and push your latest docker image.

$ docker build -t my-service .
$ nullstone launch --source=my-service --app=app --env=dev

Image Tag Immutability

This upgrade enforces image tag immutability. This is a safety precaution to prevent bad actors from redeploying your app with malicious code. Also, image tag immutability provides easier diagnostics because it guarantees that source code did not change after build. This means that you will not be able to push the same image tag for an image repository more than once. Here is example usage that will fail:

$ docker build -t my-service .
$ nullstone push --source=my-service --app=app --env=dev
$ nullstone push --source=my-service --app=app --env=dev # This will fail