Refactor how we track SENSITIVE_SERVICES

[sastels]

Description

As a Notify dec, I need to be able to change the Notify secrets.

WHY are we building? We are getting close to the max size of secrets we can encrypt with aws kms encrypt

WHAT are we building? refactor how we store SENSITIVE_SECRETS

Acceptance Criteria

• [ ] SENSITIVE_SECRETS no longer in encrypted secrets

QA Steps

• [ ] Admin views of sensitive services is still being logged appropriately.

Notes

We use a config SENSITIVE_SERVICES to help us identify admin access to sensitive services (essentially PTM right now).

The value is used by admin and currently set in the manifest repo's encrypted secrets. There is an upper limit to how large these secrets (in total) can be and still use aws kms encrypt to encrypt.

This variable is getting longer and longer as we add more services. We should consider

• moving to the admin code (this is just a list of uuids, nothing that needs to be kept secret) in the short term, and
• adding a "sensitive" flag to the services table in the long term. If we then exposed this setting to the admin settings for the service we could set it without a PR / developer assistance.

[sastels]

Now a setting in admin view for the service.