I'm trying to think of the best naming convention for storing AWS Secrets across different projects and files accessing different database. Essentially I'm removing some legacy code from many files with hard-coded credentials.
What is the best way to structure the path that the files will use to access secrets manager (ie. dev/scripts/script1 for one file, dev/scripts/script2 for another)? I don't think i can just use the name of the files since that can be the same across different projects.
Secrets Manager doesn't have functional hierarchy like Parameter Store, so the hierarchy you define doesn't have a retrieval requirement for secrets -- at least not for the built in APIs.
So it's really about what works for your environment. Think about the different factors in your environment: release phase (dev, test, prod, etc.), applications, versions, etc. and how the structure would work in actual use.
$phase/$app/$item, e.g. DEV/REPORT-THING/DbCredentials, is a common structure. Having $version in there would not generally be practical because every release you'd have to update secrets. But perhaps in your environment that makes sense.
Other "levels" might be application component or subsystem.
For some of the levels you might have a DEFAULT or COMMON that would apply, but your application code would need logic to check for DEFAULT/COMMON if it didn't find the specific entry.
For example:
For REPORT-THING/DbCredentials, you might have a value that applies to most release phases, so you might have a DEFAULT/REPORT-THING/DbCredentials. Your app would have to check for $phase/REPORT-THING/DbCredentials, and if not found, look for DEFAULT/REPORT-THING/DbCredentials. This allows you to set the values in one place, and then override them as needed. If you took this route, you'd likely want common code that encapsulated the logic, e.g. GetSecret($phase, $app, $item), and have that look for the COMMON/DEFAULT values if the specific item is not found.
