|
| 1 | +--- |
| 2 | +title: Security principles in Azure Container Apps |
| 3 | +description: Learn about the security features and best practices for Azure Container Apps, including managed identities, secrets management, and token store. |
| 4 | +services: container-apps |
| 5 | +author: craigshoemaker |
| 6 | +ms.service: azure-container-apps |
| 7 | +ms.topic: conceptual |
| 8 | +ms.date: 07/16/2025 |
| 9 | +ms.author: cshoe |
| 10 | +--- |
| 11 | + |
| 12 | +# Security principles in Azure Container Apps |
| 13 | + |
| 14 | +Azure Container Apps provides several built-in security features that help you build secure containerized applications. This article introduces the core security principles and capabilities available in Azure Container Apps. |
| 15 | + |
| 16 | +## Managed identities |
| 17 | + |
| 18 | +Managed identities eliminate the need to store credentials in your code or configuration by providing an automatically managed identity in Microsoft Entra ID. Container apps can use these identities to authenticate to any service that supports Microsoft Entra authentication, such as Azure Key Vault, Azure Storage, or Azure SQL Database. |
| 19 | + |
| 20 | +### Types of managed identities |
| 21 | + |
| 22 | +Azure Container Apps supports two types of managed identities: |
| 23 | + |
| 24 | +- **System-assigned identity**: Created and managed automatically with your container app's lifecycle. The identity is deleted when your app is deleted. |
| 25 | + |
| 26 | +- **User-assigned identity**: Created independently and can be assigned to multiple container apps, allowing identity sharing across resources. |
| 27 | + |
| 28 | +### Security benefits of managed identities |
| 29 | + |
| 30 | +- Eliminates the need to manage and rotate credentials in your application code |
| 31 | +- Reduces risk of credential exposure in configuration files |
| 32 | +- Provides fine-grained access control through Azure RBAC |
| 33 | +- Supports the principle of least privilege by granting only necessary permissions |
| 34 | + |
| 35 | +### When to use each identity type |
| 36 | + |
| 37 | +- Use **system-assigned identities** for workloads that: |
| 38 | + - Are contained within a single resource |
| 39 | + - Need independent identities |
| 40 | + |
| 41 | +- Use **user-assigned identities** for workloads that: |
| 42 | + - Run across multiple resources that share a single identity |
| 43 | + - Need preauthorization to secure resources |
| 44 | + |
| 45 | +### Managed identity for image pulls |
| 46 | + |
| 47 | +A common security pattern is using managed identities to pull images from private repositories in Azure Container Registry. This approach: |
| 48 | + |
| 49 | +- Avoids using administrative credentials for the registry |
| 50 | +- Provides fine-grained access control through the ACRPull role |
| 51 | +- Supports both system-assigned and user-assigned identities |
| 52 | +- Can be controlled to limit access to specific containers |
| 53 | + |
| 54 | +### Controlling managed identity access |
| 55 | + |
| 56 | +Container Apps allows you to control which managed identities are available to different containers: |
| 57 | + |
| 58 | +- **Init**: Available only to init containers |
| 59 | +- **Main**: Available only to main containers |
| 60 | +- **All**: Available to all containers (default) |
| 61 | +- **None**: Not available to any containers |
| 62 | + |
| 63 | +This granular control follows the principle of least privilege, limiting potential attack vectors if a container is compromised. |
| 64 | + |
| 65 | +## Secrets management |
| 66 | + |
| 67 | +Azure Container Apps provides built-in mechanisms to securely store and access sensitive configuration values like connection strings, API keys, and certificates. |
| 68 | + |
| 69 | +### Key security features for secrets |
| 70 | + |
| 71 | +- **Secret isolation**: Secrets are scoped to an application level, isolated from specific revisions |
| 72 | +- **Environment variable references**: Expose secrets to containers as environment variables |
| 73 | +- **Volume mounts**: Mount secrets as files within containers |
| 74 | +- **Key Vault integration**: Reference secrets stored in Azure Key Vault |
| 75 | + |
| 76 | +### Security best practices for secrets |
| 77 | + |
| 78 | +- Avoid storing secrets directly in Container Apps for production environments |
| 79 | +- Use Azure Key Vault integration for centralized secret management |
| 80 | +- Implement least privilege when granting access to secrets |
| 81 | +- Use secret references in environment variables instead of hard-coding values |
| 82 | +- Use volume mounts to access secrets as files when appropriate |
| 83 | +- Implement proper secret rotation practices |
| 84 | + |
| 85 | +### Key Vault integration |
| 86 | + |
| 87 | +For production workloads, store secrets in Azure Key Vault and reference them from your container app: |
| 88 | + |
| 89 | +1. Enable managed identity for your container app |
| 90 | +1. Grant the identity access to Key Vault secrets |
| 91 | +1. Reference the Key Vault secret URI in your container app configuration |
| 92 | + |
| 93 | +This approach provides: |
| 94 | + |
| 95 | +- Centralized secret management |
| 96 | +- Access control and audit logging |
| 97 | +- Automatic secret rotation |
| 98 | + |
| 99 | +## Token store for secure authentication |
| 100 | + |
| 101 | +The token store feature provides a secure way to manage authentication tokens independent of your application code. |
| 102 | + |
| 103 | +### How token store works |
| 104 | + |
| 105 | +- Tokens are stored in Azure Blob Storage, separate from your application code |
| 106 | +- Cached tokens are only accessible to the associated user |
| 107 | +- Container Apps handles token refresh automatically |
| 108 | +- The feature reduces the attack surface by eliminating custom token management code |
| 109 | + |
| 110 | +### Setting up token store |
| 111 | + |
| 112 | +To enable token store: |
| 113 | + |
| 114 | +1. Create a private blob container in Azure Storage |
| 115 | +1. Generate a SAS URL with read, write, and delete permissions |
| 116 | +1. Store the SAS URL as a secret in your container app |
| 117 | +1. Enable token store using the container app authentication configuration |
| 118 | + |
| 119 | +## Security architecture considerations |
| 120 | + |
| 121 | +When designing secure applications on Azure Container Apps, consider these architectural principles: |
| 122 | + |
| 123 | +- **Defense in depth**: Implement multiple layers of security controls |
| 124 | +- **Least privilege**: Grant only the minimum permissions necessary |
| 125 | +- **Managed service advantages**: Use the security benefits of Azure's managed services |
| 126 | +- **Secure defaults**: Start with secure configurations and only open what's necessary |
| 127 | +- **Identity as the primary security perimeter**: Center your security architecture around identity controls |
| 128 | + |
| 129 | +## Next steps |
| 130 | + |
| 131 | +- Implement [managed identities](./managed-identity.md) for secure authentication |
| 132 | +- Set up [secrets management](./manage-secrets.md) for sensitive configuration |
| 133 | +- Configure [secure image pull](./managed-identity-image-pull.md) with managed identities |
| 134 | +- Enable [token store](./token-store.md) for secure user authentication |
0 commit comments