Skip to content

Azure security best practices for Aspire deployments

When you deploy Aspire applications to Azure using the Aspire CLI or Azure Developer CLI (azd), the platform provides several security features by default. This article explains the default security posture and provides guidance on additional steps you can take to enhance the security of your applications.

This guide covers:

  • Understanding the default security configuration for Aspire deployments
  • Learning about built-in security features in Azure Container Apps
  • Implementing additional security hardening measures
  • Configuring secure communication between services
  • Applying security best practices for production deployments

When you deploy an Aspire application to Azure Container Apps using azd, several security measures are automatically configured:

Secure base images: Aspire generates container images using secure Microsoft-maintained base images that are regularly updated with security patches.

Non-root execution: Containers run with non-root user permissions by default, reducing the attack surface.

Minimal image surface: The generated containers include only the necessary runtime components, following the principle of least privilege.

Private networking: Azure Container Apps environments use virtual networks with private IP addresses for internal communication between services.

Secure service-to-service communication: Inter-service communication uses Azure Container Apps’ built-in service discovery with encrypted traffic.

HTTPS endpoints: Public-facing endpoints are automatically configured with HTTPS using Azure-managed certificates.

Managed identities: Azure Container Apps are configured with system-assigned managed identities by default, eliminating the need to store credentials in your application code.

Azure RBAC integration: Resources are deployed with appropriate role-based access control (RBAC) permissions.

Secure configuration: Application configuration is stored in Azure App Configuration when available, separate from your application code.

Environment variables: Sensitive configuration values are injected as secure environment variables rather than being embedded in container images.

While Aspire provides good security defaults, you can implement additional measures for enhanced protection:

Store sensitive configuration data and secrets in Azure Key Vault:

AppHost.cs - Add Azure Key Vault
var builder = DistributedApplication.CreateBuilder(args);
// Add Azure Key Vault resource
var keyVault = builder.AddAzureKeyVault("key-vault");
// Reference Key Vault in your services
builder.AddProject<Projects.ApiService>()
.WithReference(keyVault);

For more information, see Aspire Azure Key Vault integration.

Configure user-assigned managed identities

Section titled “Configure user-assigned managed identities”

For more granular control over permissions, use user-assigned managed identities:

AppHost.cs - Add user-assigned managed identity
var builder = DistributedApplication.CreateBuilder(args);
// Create or reference a user-assigned managed identity
var managedIdentity = builder.AddAzureUserAssignedIdentity("app-identity");
// Apply the identity to your container apps
builder.AddProject<Projects.ApiService>()
.WithReference(managedIdentity);

For detailed guidance, see Aspire Azure user-assigned managed identity integration.

Application Insights: Monitor your applications for security anomalies and performance issues:

AppHost.cs - Add Application Insights
var builder = DistributedApplication.CreateBuilder(args);
// Add Application Insights
var appInsights = builder.AddAzureApplicationInsights("monitoring");
builder.AddProject<Projects.ApiService>()
.WithReference(appInsights);

Azure Monitor: Configure alerts for suspicious activities and resource consumption anomalies.

For comprehensive guidance on Azure security, see Azure security best practices and patterns.

FAQCollaborateCommunityDiscussWatch