Preparing for production

1. Preparing for production

The architecture from the previous video is in place, but it isn't production-ready yet.

2. Application architecture

Orders can be done through the Web App and Function, but sensitive information and storage connections need proper configuration.

3. Environment variables for configuration

When you run apps in Azure, hardcoding settings into the source code is dangerous and inflexible. Instead, Azure Web Apps and Functions support configuration through environment variables. Here we can define runtime settings such as API endpoints, storage connection details, or even feature flags. If the business later changes the storage account or rotates a key, we only update the environment variable. The app doesn't need to be redeployed, and developers don't risk exposing sensitive details in their code.

4. Using key vault for secrets

Environment variables are powerful, but we don't want to store plain connection strings or passwords directly in them. That's where Azure Key Vault comes in. It acts as a central, secure store for sensitive information. In our case, the order-processing Function will rely on a secret - the storage connection. Instead of placing the secret value in configuration, we can reference the Key Vault secret by name. At runtime, Azure retrieves the secret securely and injects it into the Function environment. This keeps credentials out of both code and configuration files.

5. Granting access to the function

Of course, the Function needs permission to actually fetch the secret from Key Vault. That's where identities come into play. When we enable a Managed Identity for the Function App, Azure provides it with an identity that can be authorized to access other services.

6. Granting access to the function

We can then grant access in two ways: - RBAC (Role-Based Access Control): assigning the Function's identity a role like Key Vault Secrets User. - Access Policies: older but still common, where we explicitly allow the identity to read certain secrets. Either way, the Function can retrieve secrets without storing keys itself. RBAC, SAS keys, and other topics are covered in our "Implement Azure Security for Developers" course.

7. Connecting the storage account

The Function also needs to write orders to a storage account. Again, we have a choice: - RBAC with Managed Identity: the recommended way, where the Function's identity is given a Storage Blob Data Contributor role. - SAS keys: temporary tokens that grant scoped access. These can be rotated and also stored in Key Vault.

8. Connecting the storage account

SAS keys can even be generated at the level of individual blobs or containers, giving very granular control over which parts of storage can be accessed. This flexibility lets us align security with business needs - RBAC for simplicity and governance, SAS keys when fine-grained control or cross-tenant access is needed.

9. Wiring everything together

Once configured, the Web App calls the Function, the Function retrieves secrets securely from Key Vault, and processed orders are written into storage. No secret is hardcoded, and access is governed by Azure's security controls. This transforms our prototype into a secure, production-ready foundation.

10. Let's practice!

Now it's time to try it out yourself.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.