Closed thekaveman closed 9 months ago
Could follow this pattern / helper function get_secret_by_name
: https://github.com/cal-itp/data-infra/blob/main/packages/calitp-data-infra/calitp_data_infra/auth.py
We talked through this plan at a recent Dev Workshop, and made some adjustments based on the conversation. Those are reflected in the steps above.
The existing Django models capture both secret configuration items and non-secret configuration items. The vast majority of fields are non-secret and do not require additional controls.
For the secret configuration, values are currently maintained in Azure Key Vault and read into a new app service environment each time the app restarts (e.g. with a new deploy, or if an engineer restarts the app manually during debugging).
We want to continue to maintain the majority non-secret configuration data simply and directly via Django models and stored in the Django database.
We need a plan for how to incorporate the secret values in an environment where we do not re-create the database each time the app restarts, and thus would not (necessarily) read from Key Vault at app startup time.
Acceptance Criteria
Additional context
1313
Activities
Running list of activities related to this effort
Implementation plan
data-infra
; use Azure's python libraries to read a value from a Key Vault by secret name. Ensure the Key Vault / environment (e.g.dev
,test
,prod
) is not hardcoded; create a setting from an environment variable or similar.models.TextField
. The default field implementation stores the name of the secret. An instance method likeget_secret_value()
uses the helper script to get the value of the named secret on-demand._secret_name
_secret_name
field value to get the actual value of the secret. These properties should be named the same as the original (pre-refactor) secret field (e.g. without the_secret_name
postfix)