LG-290 Move attribute encryption away from KMS

[stevegsa]

Why: KMS is not multi-region and KMS does not allow importing or exporting keys which ties us to AWS.

How: Perform an in place migration via two steps: a deployment and a subsequent feature flag change.

Performing an in place migration in one deployment would cause destructive changes in the database that could not be rolled back upon failure and would also cause 500 errors while servers scaled in and scaled out. This PR deploys code that supports decryption for old and new formats but continues encrypting in the old format. The ability to encrypt in old and new format will be controlled via a feature flag. Upon this PR's successful deployment the next step is to enable the new encryption via the new feature flag. Shortly thereafter the rake task rotate.rake can be run to convert all the attributes to the new encryption scheme.

To accomplish this in the code we move AttributeEncryptor to DeprecatedAttributeEncryptor. Depending on the state of the feature flag the new AttributeEncryptor encrypts in old or new format. The new AttributeEncryptor decrypts in old format if it detects an old cipher text otherwise it decrypts in the new format.

Hi! Before submitting your PR for review, and/or before merging it, please
go through the following checklist:

• For DB changes, check for missing indexes, check to see if the changes
  affect other apps (such as the dashboard), make sure the DB columns in the
  various environments are properly populated, coordinate with devops, plan
  migrations in separate steps.

• For route changes, make sure GET requests don't change state or result in
  destructive behavior. GET requests should only result in information being
  read, not written. Use rotate.rake to migrate the attributes.

• For encryption changes, make sure it is compatible with data that was
  encrypted with the old code.

• For secrets changes, make sure to update the S3 secrets bucket with the
  new configs in all environments.

• Do not disable Rubocop or Reek offenses unless you are absolutely sure
  they are false positives. If you're not sure how to fix the offense, please
  ask a teammate.

• When reading data, write tests for nil values, empty strings,
  and invalid formats.

• When calling redirect_to in a controller, use _url, not _path.

• When adding user data to the session, use the user_session helper
  instead of the session helper so the data does not persist beyond the user's
  session.

• When adding a new controller that requires the user to be fully
  authenticated, make sure to add before_action :confirm_two_factor_authenticated.

[jmhooper]

Wouldn't it be simpler to re-write AttributeEncryptor to use Pii::Cipher to do this instead of depending on the UserAccessKey key class which we ultimately plan on retiring?

[jmhooper]

Check out the recent changes to Pii::Encryptor for an idea of what I'm talking about: 50958cd

[stevegsa]

That's the next logical step. I was more concerned with the db migration and leaving that useraccesskey code essentially untouched until after the we migrate the attributes. A mistake could be catastrophic. This was the minimal amount of code to get us off of kms and migrate the data. I could definitely employ all the logic in AttributeEncryptor (and debated whether I should) but ultimately thought it would be safer unencrypting through the UAK code in the short term.

[jmhooper]

I don't think we're rushing to move attribute encryption off KMS here, so we should take our time and get it right.

Let's change the attribute encryptor to do it the way we want long-term so that we avoid doing 2 migrations and potentially leaving this in a half-way state for a long time.

[stevegsa]

Sounds good. Did you want me to retain uak to do the unencrypt part of the migration? Or have that all rolled into AttributeEncryptor?

[jmhooper]

Let's keep the UAK around for legacy decrypt, that seems safer.

[jmhooper]

This looks like it is on target. Before we merge, let's write up a rollplan that let's us deploy this, and roll back new code if needed. A 2 step deploy where we deploy this and then the new code is probs the way to go.

[jmhooper]

LGTM

[monfresh]

Has a plan been documented for rolling this out in stages, per @jmhooper's comment 26 days ago?

[stevegsa]

@monfresh Yes. There is a separate document on the login.gov drive called "Attribute Encryption Rollout Plan"

[monfresh]

Can you please run make lint locally to make sure there aren't any offenses? For some reason, we occasionally end up with errors that Code Climate does not catch.

[monfresh]

Closing and reopening PR to see if it will get Snyk to respond.