API Secrets Roteren Zonder Downtime

Ergens in een config file staat een API key die drie jaar oud is. Niemand weet meer wie hem heeft aangemaakt. Klinkt herkenbaar? Dan is dit artikel relevant.

Hardcoded credentials zijn de nummer één oorzaak van API-gerelateerde datalekken. Niet omdat ontwikkelaars het niet beter weten, maar omdat secret rotation in de praktijk verrassend lastig is om goed te implementeren. De angst dat "iets kapot gaat" zorgt ervoor dat keys maanden — soms jaren — ongewijzigd blijven.

Het Dual-Key Patroon

De kern van zero-downtime rotation draait om één simpel principe: altijd twee geldige keys tegelijk hebben. Eén actieve, één die net is aangemaakt of bijna verloopt.

Het werkt als volgt:

1. Genereer een nieuwe key (key B) terwijl de huidige (key A) nog geldig is
2. Deploy key B naar alle consumers
3. Wacht tot alle services key B gebruiken
4. Trek key A in

Klinkt simpel. In de praktijk zit de complexiteit in stap 2 en 3: hoe weet je zeker dat alle services zijn overgeschakeld?

Implementatie met Azure Key Vault

Azure Key Vault ondersteunt versioning van secrets out-of-the-box. Dat maakt het een logische plek om rotation te orkestreren.

// Secret ophalen met de nieuwste versie — geen hardcoded versie-ID
var client = new SecretClient(
    new Uri("https://mijn-vault.vault.azure.net/"),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync("api-key-externe-service");
string apiKey = secret.Value;

De truc zit hem in het niet cachen van de secret voor onbepaalde tijd. Een TTL van 5-15 minuten is een goede balans tussen performance en rotatietijd.

public class RotatingSecretProvider
{
    private readonly SecretClient _client;
    private string _cachedSecret;
    private DateTime _cacheExpiry;
    private readonly TimeSpan _cacheTtl = TimeSpan.FromMinutes(10);

    public async Task<string> GetSecretAsync(string name)
    {
        if (_cachedSecret != null && DateTime.UtcNow < _cacheExpiry)
            return _cachedSecret;

        var secret = await _client.GetSecretAsync(name);
        _cachedSecret = secret.Value.Value;
        _cacheExpiry = DateTime.UtcNow.Add(_cacheTtl);
        return _cachedSecret;
    }
}

Geautomatiseerde Rotation met een Azure Function

Handmatige rotation is beter dan geen rotation, maar het schaalt niet. Een Azure Function met een timer trigger kan dit volledig automatiseren.

[Function("RotateApiKeys")]
public async Task Run(
    [TimerTrigger("0 0 2 */30 * *")] TimerInfo timer,  // elke 30 dagen om 02:00
    FunctionContext context)
{
    var logger = context.GetLogger("RotateApiKeys");
    
    // Stap 1: Genereer nieuwe key bij de externe service
    var newKey = await _externalService.RegenerateSecondaryKeyAsync();
    
    // Stap 2: Sla op in Key Vault als nieuwe versie
    await _secretClient.SetSecretAsync("external-api-key", newKey);
    
    // Stap 3: Wacht tot consumers de nieuwe key oppikken
    await Task.Delay(TimeSpan.FromMinutes(20));
    
    // Stap 4: Deactiveer de oude key
    await _externalService.RevokeOldKeyAsync();
    
    logger.LogInformation("Key rotation voltooid: {Time}", DateTime.UtcNow);
}

Let op die Task.Delay — in een echte productie-setup wil je dit robuuster aanpakken. Een betere aanpak is om de rotation in twee fasen te splitsen: één function die de nieuwe key genereert, en een tweede die na een uur de oude intrekt.

Veelgemaakte Fouten

Een paar patronen die regelmatig voorbijkomen in codebases:

Fout	Waarom het misgaat	Oplossing
Secret in environment variable bij deploy	Blijft staan tot volgende deploy, soms weken	Runtime ophalen uit vault met korte TTL
Eén key voor alle omgevingen	Compromis in staging = compromis in productie	Aparte keys per omgeving, apart roteren
Rotation zonder monitoring	Stille failures totdat een klant belt	Alert op 401/403 spikes na rotation
Geen fallback bij vault-uitval	Vault down = hele applicatie down	Gecachte secret als fallback, met korte TTL

Monitoring Na Rotation

Dit stuk wordt vaak vergeten. Na elke rotation moet er actieve monitoring draaien die checkt of alles nog werkt. Simpelste aanpak: een health check endpoint dat een lightweight API call doet met de huidige credentials.

# Simpele health check na rotation
curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer $(az keyvault secret show \
    --vault-name mijn-vault \
    --name external-api-key \
    --query value -o tsv)" \
  https://api.externe-service.nl/health

Als dit een 401 teruggeeft binnen 30 minuten na rotation, dan is er iets misgegaan en moet er automatisch worden teruggerold.

Git Pre-commit Hooks als Vangnet

Zelfs met de beste rotation-strategie lekt er soms een key in code. Een pre-commit hook voorkomt dat secrets überhaupt in de repository terechtkomen.

#!/bin/bash
# .git/hooks/pre-commit

# Simpele regex check op veelvoorkomende secret-patronen
PATTERNS="(ghp_[a-zA-Z0-9]{36}|AKIA[0-9A-Z]{16}|sk-[a-zA-Z0-9]{48})"

if git diff --cached --diff-filter=ACM | grep -qE "$PATTERNS"; then
    echo "❌ Mogelijke secret gevonden in staged files!"
    echo "Gebruik een vault of environment variable in plaats van hardcoded keys."
    exit 1
fi

Tools als gitleaks of trufflehog doen dit uitgebreider, maar een simpele regex hook vangt al 80% van de gevallen.

Samenvatting

Secret rotation hoeft niet eng te zijn. Het dual-key patroon voorkomt downtime, een vault met versioning maakt het beheersbaar, en automatisering via een timer-triggered function zorgt ervoor dat het daadwerkelijk gebeurt. Combineer dat met monitoring na rotation en pre-commit hooks als vangnet, en het risico op gelekte of verouderde credentials daalt drastisch.

Begin klein. Pak de key die het langst ongewijzigd is — waarschijnlijk weet iedereen in het team welke dat is — en zet daar rotation voor op. De rest volgt vanzelf.