End-To-End TLS Setup mit einer .NET Web Application auf AKS Cluster 

Inhaltsverzeichnis

1. Umgebung
2. Die Lösung
3. Zusammenfassung

Die Sicherung des Netzwerkverkehrs wird über die nächsten Jahre hinweg immer wichtiger. Immer häufigere Security-Breaches mit immer ausgefeilteren Angriffen, veranlassen alle IT-Ingenieure nach effektiven Möglichkeiten zum Schutz ihrer Systeme zu suchen. Eine der Optionen ist Encrypted Traffic mit Transport Layer Security (TLS). Dies ermöglicht die Kommunikation mit Netzwerkdiensten über einen sicheren Kanal.

TLS (früher bekannt als SSL) schützt vor zahlreichen Arten von Cyberangriffen wie Man-in-the-Middle, Domain-Diebstahl, Domain-Hijacking und mehr. Dieses Protokoll wird auch während des Authentifizierungsprozesses verwendet.

Unabhängig davon, welche modernen Technologien Sie für Ihr Projekt auswählen, bleiben einige bekannte Muster relevant. Serverlose Systeme, Kubernetes- oder Platform-as-a-Service-Lösungen, stehen noch vor den gleichen Herausforderungen, welche die monolithischen und lokal gehosteten Infrastrukturen bedrohen.

Umgebung

Das häufigste Szenario der Implementierung der Traffic Encryption mit einem Application-Gateway, bedeutet das Ende der TLS. Während der Client-Server-Kommunikation wird der verschlüsselte Datenverkehr nur zwischen dem Kunden und dem Application-Gateway aufgebaut. Unverschlüsselte Backend-Kommunikation wirft, obwohl sie ihre Vorteile hat – vor allem in der Leistung – auch Sicherheitsbedenken auf. Es besteht die Gefahr, dass ein Angreifer bereits in der Infrastruktur präsent ist und hofft, die unverschlüsselte Kommunikation von innen auszunutzen. Aus diesem Grund ist End-to-End-TLS in sensiblen Umgebungen so wichtig.

Infrastruktur

In diesem Beispiel werde ich die folgende Infrastruktur begutachten:

Wie Sie sehen können, wird ein AKS-Cluster hinter einem Azure-Application-Gateway eingerichtet. Um die End-to-End-TLS-Kommunikation zu demonstrieren, benötigen wir eine Webanwendung, einen Ingress-Controller und ein Zertifikat zum Verschlüsseln des Datenverkehrs. Sobald der Application-Gateway-Ingress-Controller (AGIC) erfolgreich auf dem Cluster installiert wurde, übernimmt er die Konfiguration der Azure-Ressource. Dazu kümmert es sich um die Konfigurationssynchronisierung des Gateways, indem es Anmerkungen aus der Ingress-Definition liest und sie auf die Cloud-Ressource anwendet.

In diesem Szenario sollte das Backend-Kommunikationsprotokoll auf „https“ eingestellt werden und falls der Client eine Anfrage über http sendet, wird diese auf https umgeleitet. Dies sind die Anmerkungen, die das bewirken können:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp
  annotations:
    3ubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/ssl-redirect: “true”
    appgw.ingress.kubernetes.io/backend-protocol: https

Das fragliche Zertifikat ist ein Full-Chain-Zertifikat mit einem privaten Schlüssel. Es sollte in Azure Key Vault hochgeladen und dann nach Identität als Kubernetes-Secret abgerufen werden. Die Zertifikatsdatei wird mithilfe der geheimen Anbieterklasse in einem Pod gemountet.

Die Integration von Azure-Ressourcen und einem AKS-Cluster ist möglich, indem die verwaltete Identitätsressource im Azure-Abonnement und die benutzerdefinierte Ressourcendefinition (CRD) von AzureIdentity in Kubernetes zugeordnet werden. Dieser Mechanismus ermöglicht es dem Cluster, sich mit der Azure-API zu authentifizieren und die API zu verwenden, um die erforderlichen Aktionen auszuführen.

Web Application

Um die Dinge so einfach wie möglich zu gestalten, ist die in diesem Beispiel verwendete Web-App die WebApp-Vorlage in der sechsten Version von .NET von Visual Studio. Die einzigen Änderungen sind die hinzugefügte Docker-Unterstützung und das https-Protokoll.

Die offizielle Microsoft-Dokumentation schlägt vor, dass zur Erzwingung der Verkehrsverschlüsselung eine Anweisung zur Datei „program.cs“ hinzugefügt werden muss.

 

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
var app = builder.Build();
app.UseHttpsRedirection();
.
.
.
app.Run();

 

Außerdem ist ein Verweis auf die Zertifikatsdatei erforderlich. Sie können dies über Anwendungseinstellungen oder Umgebungsvariablen tun:

"Certificates": {

      "Default": {

         "Path": "<path to .pem/.crt file>",

          "KeyPath": "<path to .key file>"     

}

    }

Die Einschränkungen von .NET

An diesem Punkt scheint es, dass wir das richtige Setup haben. Infrastruktur, Applikation, Zertifikate werden nach Vorschrift konfiguriert. Das bedeutet, dass alles funktionieren wird, richtig? Leider ist das nicht der Fall und die Anwendung wird abstürzen.

Der Grund dafür ist, dass .NET keine vollständigen Chain-Certifikates unterstützen kann. Es nimmt die Zertifikatsdatei aus dem Volume-Mount und verwendet nur das letzte Zertifikat (Blatt). Problematisch wird dies nur dadurch, dass sich die App hinter dem Azure Application Gateway befindet. Damit die Anwendung funktioniert, müssen sowohl das Application-Gateway als auch der Back-End-Server während des TLS-Handshakes mindestens den Zwischen- und Blattteil der Zertifikatskette austauschen.

Die Lösung

Die Lösung besteht darin, die auf GitHub veröffentlichten Erweiterungen zu verwenden. Sie können das Laden von TLS-Zertifikaten für .NET 6.0 Kestrel-Webanwendungen aktivieren, das Aktualisieren von Zertifikaten ermöglichen sowie die Kompatibilität mit HTTP/3 sicherstellen, sodass Sie TLS in Ihrem Projekt implementieren können.

 

using Microsoft.AspNetCore.Server.Kestrel.Core;
using Microsoft.AspNetCore.Server.Kestrel.Https;
using System.Net.Security;
using System.Security.Cryptography.X509Certificates;

namespace tlsE2eAgic
{
 public static class TlsListenOptionsExtensions
  {
   public static ListenOptions UseHttpsWithFullChain(this ListenOptions listenOptions, string certPath, string keyPath, string? password = null)
{
    ArgumentNullException.ThrowIfNull(certPath);
    ArgumentNullException.ThrowIfNull(keyPath);

    var env = listenOptions.ApplicationServices.GetRequiredService<IWebHostEnvironment>();

    var fullCertPath = Path.Combine(env.ContentRootPath, certPath);
    var fullkeyPath = Path.Combine(env.ContentRootPath, keyPath);

    var leafCertWithKey = password switch
    {
     null => X509Certificate2.CreateFromPemFile(fullCertPath, fullkeyPath),
     _ => X509Certificate2.CreateFromEncryptedPemFile(fullCertPath, password.AsSpan(), fullkeyPath)
    };

    // Import the full cert chain
    var fullChain = new X509Certificate2Collection();
    fullChain.ImportFromPemFile(certPath);

    var options = new SslServerAuthenticationOptions
    {
     // Don't go online to retrieve cert chain
     ServerCertificateContext = SslStreamCertificateContext.Create(leafCertWithKey, fullChain, offline: true)
    };

    return listenOptions.UseHttps(new TlsHandshakeCallbackOptions
    {
     OnConnection = context => new(options)
    });
   }
  }
 }

 

 

Mit dem obigen Code müssen Sie der Anwendung lediglich die Umgebungsvariablen certPath und keyPath bereitstellen. Sie können beide denselben Wert haben, da die Anwendung Zertifikate und Schlüsselinhalte in derselben Datei verarbeitet. Die verschlüsselte Kommunikation wird dann auf dem User -> Application Gateway -> Web Application aufgebaut.

Zusammenfassung

Die oben beschriebene Lösung ist im Wesentlichen ein Workaround, erfüllt jedoch ihren Zweck indem sie den internen Datenverkehr der Backend-Infrastruktur sichert. Auch wenn End-to-End-TLS kein neues Konzept in der IT-Welt ist, fehlt es immer noch an einer nativen Lösung für .NET. Das kommende .NET 7 kann endlich die lang erwartete Funktionalität der Unterstützung des vollständigen Chain-Certificates in der Kestrel-Middleware einführen. Laut Microsoft wurde das Problem mit der Unterstützung der vollständigen Zertifikate nach dotnet-7.0-preview4 verschoben und könnte bald veröffentlicht werden.

Wir empfehlen Ihnen vorerst, die beschriebene Lösung zu verwenden, da dies die beste Möglichkeit ist TLS in einer .NET-Webanwendung zu implementieren.