4 ms·
Yeah, prefixing your keys with your service name like SRVCE_{KEY} is the way to go. Bonus: adding SRVCE_PRVT_{KEY} and SRVCE_PUB_{KEY}.
by gl-prod 4y ago
Yeah, prefixing your keys with your service name like SRVCE_{KEY} is the way to go.
Bonus: adding SRVCE_PRVT_{KEY} and SRVCE_PUB_{KEY}.
- rytis 4y agoAnd while we're at it, I think saving two chars isn't going to do much to prevent global warming, and let's just use more readable SERVICE_{KEY} and SERVICE_PUB_{KEY} (as opposed to having scratch your head thinking "did I call it SRV, SVC, SRVC, SRVCE, ...?")
- gl-prod 4y agoI meant as an abbreviation, like GitHub becomes ghp_XXXXXXXXX. But yeah anything is better than just random characters.
- hawski 4y agoI think OP meant to use the actual name of the service. For example FOOBARINC_{KEY} I also think that it should look just a bit cryptic to make a person unsure if they can meddle with the string.
- miohtama 4y agoThere is already RTC 8958 Secret token scheme for this, so you do not need to invent your own prefix https://datatracker.ietf.org/doc/html/rfc8959 https://datatracker.ietf.org/doc/html/rfc8959
- throwaway290 4y agoI see this standard linked here a lot. Did anyone read it though? It only helps with identifying whether a string is a secret, not at all the service or environment where the secret applies.
- miohtama 4y agoIf any value does not natively support secret token sceme, you can apply secret-token: prefix and then strip it during the usage.