Laden...

Https Verbindung zu ASPNETCore-Api in Container hinter ReverseProxy

Erstellt von emuuu vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.139 Views
emuuu Themenstarter:in
286 Beiträge seit 2011
vor 4 Jahren
Https Verbindung zu ASPNETCore-Api in Container hinter ReverseProxy

Guten Tag zusammen,

ich habe mal eine Verständnisfrage bzw. ein Problem.

Ich habe eine Api in einem Container. Vor den Container ist Traefik geschaltet. Die Verbindung zur Api soll logischerweise via https erfolgen.

In Traefik ist https via LetsEncrypt-Zertifikat automatisiert aktiviert. Sprich die Verbindung Client <-> Traefik ist abgesichert und sollte nicht das Problem sein.

Um in der Api https zu verwenden konfiguriere ich das Ganze so:


        public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseKestrel(options =>
                {
                    options.Listen(IPAddress.Any, 5001, listenOptions =>
                    {
                            listenOptions.UseHttps(@"C:\https\test-certificate.pfx", "asdf1234");
                    });
                })
                .UseStartup<Startup>()
                .ConfigureLogging(builder =>
                {
                    builder.ClearProviders();
                    builder.AddSerilog();
                });


Das hat bisher auch problemlos funktioniert, allerdings ist es ja mittlerweile innerhalb des Dockercontainers so, dass man per Default nur noch User und nicht mehr Administrator ist. Zudem möchte ich von nanoserver-2016sac auf 1803 wechseln.

Ich habe verschiedene Ansätze (die auch rein technisch funktionieren), wobei ich nicht sagen kann, wie sicher/unsicher das ist.

Das ursprüngliche Problem ist, dass das Einlesen des Zertifikats wie oben gezeigt für einen User nicht möglich ist und Admin-Rechte verlangt.
Eine Lösung wäre es im Dockerfile "USER ContainerAdministrator" mitzugeben.
Wobei die Änderung in Docker wohl nicht von ungefähr kommt und ich die daher nicht grundsätzlich unterlaufen möchte.

Zweiter Ansatz wäre daher, das Zertifikat direkt zu installieren und es dann in der Konfiguration nur aus dem Zertifikatsspeicher auszulesen:


COPY --from=tool /Windows/System32/certoc.exe .
USER ContainerAdministrator
RUN certoc.exe -addstore root root-ca.cer
USER ContainerUser

Problem: certoc.exe gibt es im 1709- und 1803-Image nicht mehr, nur in sac2016

Im Container kein SSL verwenden. Erscheint mir als die schlechtestes Option, da die Verbindung dann ab Traefik <-> Api unverschlüsselt wäre und es zudem mit sowas wie IdentityServer Probleme geben würde.

Habt ihr einen anderen Ansatz oder funktioniert atm einfach nur die ContainerAdministrator-Variante?

Beste Grüße
emuuu

2+2=5( (für extrem große Werte von 2)

16.835 Beiträge seit 2008
vor 4 Jahren

Konzeptfehler: das Zertifikat hat im Container nichts zu suchen.
Warum ist es überhaupt hart drin?

Übergib das Zertifikat als Container Variable (oder ziehe Dir es aus einem KeyValue Store (in Azure zB KeyVault)) und erstell Dir ein X509Certificate2 Objekt.
Das X509Certificate2-Objekt kannst Du dann UseHttps übergeben,

emuuu Themenstarter:in
286 Beiträge seit 2011
vor 4 Jahren

Konzeptfehler: das Zertifikat hat im Container nichts zu suchen.
Warum ist es überhaupt hart drin?

Ich mounte nen Volume im Container als C:/https in welchem ich das Zertifikat übergebe - fällt das auch schon unter hart?
Da die in Traefik identisch geladen werden (als json), dachte ich, dass das vom Konzept her in Ordnung sein sollte

2+2=5( (für extrem große Werte von 2)

16.835 Beiträge seit 2008
vor 4 Jahren

Gut, ein Volume ist schon 1000x besser als dass das Cert im Container liegt - war nicht ersichtlich, dass Du das so machst.
Bin trotzdem der Meinung, dass das prinzipiell eher nach einem Workaround klingt, bevor es Docket Secrets und Konsorten gab.
Warum nutzt ihr denn Volumes und kein entsprechendes Secret Management?

Denn UseHttps braucht eigentlich(?) keine Adminrechte.
Ich vermute, dass es an der Stelle an Windows bzw. dem Cert Store vom Container liegt.

Leider ist mein Nanoserver-Wissen hier nicht weiter vorhanden, weswegen ich Dir nicht sagen kann, ob das ein guter Weg so ist.
Dass Microsoft das certoc Tool entfernt hat, wird seinen Grund haben (den ich aber aktuell auch nicht kenne - vermute aber es ist das Thema, dass ein Cert halt nicht in den Container gehört).