DataProtection and scaling /8 #33104
Conversation
I think my statement was correct, but I agree that it could mislead new users and should be updated. It is true that someone has to decide and configure where that shared storage location will be, but that someone may not be the app author (e.g. in ACA or App Services on Windows). |
aspnetcore/security/data-protection/configuration/scaling/includes/scaling7.md
Show resolved
Hide resolved
| author: acasey | ||
| description: Learn how to configure Data Protection in ASP.NET Core for multi-instance apps. | ||
| ms.author: acasey | ||
| ms.custom: mvc |
There was a problem hiding this comment.
@Rick-Anderson Do you happen to know what this means/does? I just copied it from the overview.
Co-authored-by: Andrew Casey <amcasey@users.noreply.github.com>
| * Newly created Azure Container Apps built using ASP.NET Core Kestrel. For more information see [Autoscaling considerations | ||
| ](/azure/container-apps/dotnet-overview#autoscaling-considerations). | ||
|
|
||
| The following distributed environments do ***NOT*** provide automatic key storage in a shared location: |
There was a problem hiding this comment.
I think I might characterize these as scenarios where keys will not be shared across instances (even if they have a shared location).
| * Separate [deployment slots](/azure/app-service/deploy-staging-slots), such as Staging and Production. | ||
| * Azure Container Apps built using ASP.NET Core Kestrel 7.0 or earlier. For more information see [Autoscaling considerations | ||
| ](/azure/container-apps/dotnet-overview#autoscaling-considerations). | ||
| * Asp.net core apps hosted on multiple non-Azure VMs that don't use server affinity. |
There was a problem hiding this comment.
Server affinity doesn't get you shared storage, it makes shared storage unnecessary.
There was a problem hiding this comment.
Out of curiosity, how are we going to keep this up-to-date if/when non-Azure clouds add support for this (which they can straightforwardly do, if they're interested)?
Co-authored-by: Andrew Casey <amcasey@users.noreply.github.com>
|
|
||
| Apps that are running in distributed environments that don't configure Data Protection automatically need to explicitly configure Data Protection. See <xref:security/data-protection/configuration/scaling> for environments that require explicit Data Protection configuration and those that don't. | ||
|
|
||
| Under the default configuration, a unique key ring is stored on each node of the web farm. Consequently, each web farm node can't decrypt data that's encrypted by an app on any other node. The default configuration isn't generally appropriate for hosting apps in a web farm. Sticky sessions using [ARR Affinity](/azure/app-service/manage-automatic-scaling?#how-does-arr-affinity-affect-automatic-scaling) is an alternative to implementing a shared key ring is to always route user requests to the same node. However, ARR can reduce the scalability of a web farm. |
There was a problem hiding this comment.
| Under the default configuration, a unique key ring is stored on each node of the web farm. Consequently, each web farm node can't decrypt data that's encrypted by an app on any other node. The default configuration isn't generally appropriate for hosting apps in a web farm. Sticky sessions using [ARR Affinity](/azure/app-service/manage-automatic-scaling?#how-does-arr-affinity-affect-automatic-scaling) is an alternative to implementing a shared key ring is to always route user requests to the same node. However, ARR can reduce the scalability of a web farm. | |
| Under the default configuration, a unique key ring is stored on each node of the web farm. Consequently, each web farm node can't decrypt data that's encrypted by an app on any other node. The default configuration isn't generally appropriate for hosting apps in a web farm. Sticky sessions using [ARR Affinity](/azure/app-service/manage-automatic-scaling?#how-does-arr-affinity-affect-automatic-scaling) is an alternative to implementing a shared key ring. However, ARR can reduce the scalability of a web farm. |
There was a problem hiding this comment.
Not sure if this is the actual fix, but something's off with this sentence.
| The following distributed environments provide automatic key storage in a shared location: | ||
|
|
||
| * [Azure apps](/aspnet/core/security/data-protection/configuration/default-settings). For more information see <xref:security/data-protection/configuration/default-settings#key-management>. | ||
| * Newly created Azure Container Apps built using ASP.NET Core. For more information see [Autoscaling considerations |
There was a problem hiding this comment.
I've asked ACA for a date we can use in place of "newly created".
| The following distributed environments provide automatic key storage in a shared location: | ||
|
|
||
| * [Azure apps](/aspnet/core/security/data-protection/configuration/default-settings). For more information see <xref:security/data-protection/configuration/default-settings#key-management>. | ||
| * Newly created Azure Container Apps built using ASP.NET Core. For more information see [Autoscaling considerations |
There was a problem hiding this comment.
@claudiaregio Can you remember how we scoped this? I've suddenly remembered that this might only affect Aspire apps for now?
| * Newly created Azure Container Apps built using ASP.NET Core. For more information see [Autoscaling considerations | ||
| ](/azure/container-apps/dotnet-overview#autoscaling-considerations). | ||
|
|
||
| The following scenarios do ***NOT*** provide automatic key storage in a shared location: |
There was a problem hiding this comment.
This list still feels off to me. What if we framed it as a list of caveats and dropped the mention of non-Azure and ARR?
If ARR is important, we could say that it's an alternative (that applies everywhere, not just non-Azure) though, personally, I think we covered that adequately in the intro.
Rick-Anderson
changed the title
Fixes #32530
Replaces #33086
@amcasey maybe I don't understand the topic, In your draft " However, when an app scales horizontally by adding more instances, it becomes necessary to explicitly configure Data Protection to establish a shared storage location for Data Protection keys. "
But not in all horizontal scaling (right). It's important to not assume much knowledge for newer users.
I think we can lower the friction if I use your draft to create the article.
Internal previews