You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 26, 2022. It is now read-only.
Would like to propose enhancements in the current nomenclature being used when passing key to the GCP Secret Manager backend. The existing implementation takes the complete URI as part of the key i.e. projects/111122223333/secrets/my-secret/versions/latest. This means that the metadata information (i.e. project id) is being passed with the key.
Also, GCP Secret manager follows a very simplistic approach when defining secret keys, there is no support yet for hierarchy / tagging, thus secret key naming convention should align with with the way those are defined in GCP.
Fix to this is to pass the project id in the spec (as optional) and if its missing, then can be picked up from the SA credentials.
Additionally, version can be another key under "data" section and again as optional. If not passed, then the GCP secret manager backend will always fetch the latest one.
The text was updated successfully, but these errors were encountered:
This ticket is related to #301 (comment)
Would like to propose enhancements in the current nomenclature being used when passing key to the GCP Secret Manager backend. The existing implementation takes the complete URI as part of the key i.e. projects/111122223333/secrets/my-secret/versions/latest. This means that the metadata information (i.e. project id) is being passed with the key.
Also, GCP Secret manager follows a very simplistic approach when defining secret keys, there is no support yet for hierarchy / tagging, thus secret key naming convention should align with with the way those are defined in GCP.
Fix to this is to pass the project id in the spec (as optional) and if its missing, then can be picked up from the SA credentials.
Additionally, version can be another key under "data" section and again as optional. If not passed, then the GCP secret manager backend will always fetch the latest one.
The text was updated successfully, but these errors were encountered: