I'm trying to find the best way to manage secrets when using Bicep, especially since I can't use key vault references because the key vault is created within the infrastructure as code (IaC) setup. For most secrets, like connection strings, I can dynamically retrieve them from previously created resources and store them in the key vault. However, I'm uncertain about handling JWT keys. Hardcoding these values into the IaC is not a viable solution. Also, manually inserting the JWT secret after the initial pipeline run seems like a messy approach. I can't use random number generators like newGuid() either, as that would affect existing authenticated user sessions and is not a secure method. Any suggestions?
1 Answer
A solid approach is to utilize multi-staged Bicep deployments. Start with infrastructure provisioning, including setting up the Azure Key Vault (AKV), followed by configuring User Assigned Managed Identities (UAMI) permissions, and finally loading your application configuration. But keep in mind, if you're storing JWT in the AKV, the client should typically manage the JWT for signing tokens directly. Just a thought on the design!
That's true! The JWT secret is necessary for signing the tokens, but I still can't wrap my head around using connection strings with credentials instead of Azure Active Directory. It seems like a legacy choice without much logic behind it.