Secret Management and Key Rotation

In a production multi-instance deployment, all application servers must share the same Data Protection key ring — if Server A encrypts a session cookie and Server B cannot decrypt it, users are randomly logged out depending on which server their request hits. Key management — where keys are stored, how they are encrypted at rest, how long they live, and how they are rotated — is an operational security concern that must be planned before going to production. This lesson covers the key storage and rotation patterns used in cloud-native ASP.NET Core deployments.

Key Ring Configuration for Production #

// ── Production key storage — Azure Blob + Key Vault ───────────────────────
// Keys XML file stored in Azure Blob Storage (all instances read/write here)
// Keys encrypted with Azure Key Vault (key encryption key — never leaves vault)

builder.Services.AddDataProtection()
    .SetApplicationName("BlogApp")        // must match across all services
    .SetDefaultKeyLifetime(TimeSpan.FromDays(90))
    .PersistKeysToAzureBlobStorage(
        new Uri(builder.Configuration["DataProtection:BlobUri"]!),
        new DefaultAzureCredential())
    .ProtectKeysWithAzureKeyVault(
        new Uri(builder.Configuration["DataProtection:KeyVaultKeyUri"]!),
        new DefaultAzureCredential());

// ── What this achieves: ────────────────────────────────────────────────────
// - All 10 pods read the SAME key XML from Blob Storage
// - The key XML is encrypted with a Key Vault key (server never sees raw key material)
// - Key rotation: every 90 days a new key is added; old keys kept for decryption
// - Key Vault manages the master key; audits all key operations
// - Managed Identity authentication — no stored credentials

Key Rotation and Auditing #

// ── Key rotation — automatic, transparent to the application ──────────────
// When a key approaches expiry (within 5 days of 90-day lifetime by default),
// Data Protection automatically creates a new key. New payloads are protected
// with the new key. Old payloads protected by the expiring key can still be
// decrypted until the key is revoked or deleted.

// ── IKeyEscrowSink — audit all key creation events ────────────────────────
public class KeyAuditSink(ILogger<KeyAuditSink> logger) : IKeyEscrowSink
{
    public void Store(Guid keyId, XElement element)
    {
        // Log key creation for compliance auditing
        // DO NOT log the actual key material (element contains it)
        logger.LogInformation(
            "New data protection key created. KeyId={KeyId} CreatedAt={CreatedAt}",
            keyId, DateTime.UtcNow);
    }
}

builder.Services.AddDataProtection()
    .SetApplicationName("BlogApp")
    .AddKeyEscrowSink<KeyAuditSink>();   // register audit sink

// ── Viewing active keys (for operational visibility) ──────────────────────
// IKeyManager can be injected to inspect the key ring:
public class KeyRingController(IKeyManager keyManager) : ControllerBase
{
    [HttpGet("/admin/keys"), Authorize(Roles = "Admin")]
    public IActionResult GetKeyInfo()
    {
        var keys = keyManager.GetAllKeys().Select(k => new
        {
            k.KeyId,
            k.CreationDate,
            k.ExpirationDate,
            k.IsRevoked,
        });
        return Ok(keys);
    }
}

Common Mistakes #

Mistake 1 — Using in-memory key storage in production (lost on restart) #

❌ Wrong — default in-memory key ring is lost on pod restart; all protected data becomes unreadable:

builder.Services.AddDataProtection();   // no PersistKeysTo* call — in-memory only!

✅ Correct — always configure a persistent key storage provider in production.

Mistake 2 — Changing SetApplicationName on a live system (invalidates all sessions) #

❌ Wrong — renaming silently logs out all users and invalidates all tokens.

✅ Correct — treat the application name as immutable once in production; plan any changes as a coordinated migration.