Support providing Registry notification headers as Kubernetes secrets
Logic
- Move registry notifications to global. This is because we may need to pass the header to Rails application too.
-
We use an array (of maps) to list headers, not a map (of maps) like original registry configuration. This is a visible difference.This was changed. - We do not transform contents of secret to an array, but just place its contents as value to the header key. It is on the user to populate the secret in the proper format (array of strings).
- Sensitive and regular headers are distinguished by
the keys in the map. If there is a keytype of the value. If it is a map, we assume it is a secret-backed one, else, we assume it is a regular one.value
, we deem it to be a regular one. If there is a keysecret
, we deem it to be a sensitive one. - Regular headers are placed as-is in the config file.
- Sensitive headers are placed as
<name>: SECRET_<secret name>_<secret key>
in the config file. - We mount the sensitive headers to the registry configuration directory, under a subdirectory called
notifications
in the formatSECRET_<secret name>_<secret key>
. - In the initContainer, we do a find-and-replace on
SECRET_*
strings with the contents of the respective files innotifications
subdirectory. This is similar to how we handledhttpSecret
,ACCESS_KEY
,SECRET_KEY
etc.
Closes #1969 (closed)
Edited by Balasankar 'Balu' C