Skip to content

Latest commit

 

History

History
106 lines (75 loc) · 3.46 KB

README.adoc

File metadata and controls

106 lines (75 loc) · 3.46 KB
Raw

libats slick support

Column Encryption

Configuration

To use this feature you’ll need to add the following settings to your application.conf:

ats {
  database {
    encryption {
      salt = "<some salt, at least 8 bytes, base64 encoded"
      password = "some password, 64 chars long"
    }
  }
}

A valid salt can be generated with:

python3 -c 'import base64; import secrets; print(base64.b64encode(secrets.token_bytes(8)).decode("utf-8"))'

A valid password can be generated with:

pwgen --capitalize --numerals --secure 64 1

Usage

See ota-tuf/keyserver for examples on how to use this feature.

Changing encryption keys

Important
 This is a dangerous operation, test thoroughly before running this in a production server

The encryption key used to encrypt existing data can be changed with the following command:

sbt run-main com.advancedtelematic.libats.slick.db.SlickEncryptionKeyChangeApp idColumn tableName column oldSalt oldPass newSalt newPass

For example:

sbt run-main com.advancedtelematic.libats.slick.db.SlickEncryptionKeyChangeApp key_id keys private_key zP4TEcmyaZw= H83tIxLhILdshamQFxqULXlkLKF1ytrowuBLNIHs5aFq994Y6OxVpXTJHesValH7 80R1NXHKHeQ= WcywlQrO7NXk2dQeAtsHO3FYUdfRXfVsmTOZR9934Tf0p14JD5VYeTIGIJv27sXk

Pay attention to warnings and log messages when running this command. The command might leave the database in an inconsitent case in case it cannot decrypt or encrypt some columns in the database.

Migrations

Migrations are supported through the BootMigrations trait, mixed in with BootApp or DaemonApp.

Synchronous/Asynchronous Migrations

When using BootMigrations, both SQL and Scala migrations are executed synchronously.

This means the app will not respond to HTTP GET /health until the migrations are executed, which can take more time than kubernetes is configured to wait. This means that to run the migration you might need to adjust the liveness timeout for your current deployment and adjust it back after running the migration.

You can instead set ASYNC_MIGRATE=true and this will cause migrations to run in the background while the server starts and continues serving requests.

App level migrations

Often we need to write app level migrations in scala and not SQL. These are supported through flyway java migrations.

All app level migrations should be idempotent and implemented as flyway repeatable migrations.

To add a new app level migration you need to create a class named R__YourMigration extending AppMigration in the _root_.db.migrations package in your project. This migration will be picked up by flyway and executed on boot if DB_MIGRATE=true is set for your app.

There is an example of an app level migration on the service blueprint template.

Once executed, the migration will not be executed again until the checksum column of the schema_version database table is changed. If you need to force the re-execution of the migration on the next app boot, you can update the schema_version table for that migration:

UPDATE schema_version SET checksum = NULL where installed_rank = '<current installed_rank for your migration';

Note that changing the name of the migration class will also force a re-execution of the migration.