Closed AceHack closed 8 years ago
@blowdart
I don't know if its "approved" yet, but for SF you should be using WebListener for your directly externally facing microservice layer, then can use Kestrel for your internal microservice to microservice communications on its private network.
Hopefully in the future can use Kestrel as the external layer, but not currently.
The article is wrong. Kind of.
Remember we don't recommend you expose Kestrel to the internet. Treat it as an app server, not a web server. So the TLS support is for doing end to end encryption, you terminate at the proxy, and then the proxy talks SSL to Kestrel.
And to be technically correct, we don't support SSL, we only support TLS :)
So just to be clear without a 3rd party proxy, there is no support for TLS? I just want to make sure I understand.
It is a scenario that is "not supported" for an externally facing webserver; when you need to use a reverse proxy.
You can use ssl with kestrel on a closed private network (note: not an internal user exposed network); for example ssl between the proxy and kestrel for end-to-end encryption or inter-communications between microservices.
An example of how to use SSL with Kestrel is in the SampleApp project in the Kestrel samples directory https://github.com/aspnet/KestrelHttpServer/blob/dev/samples/SampleApp/Startup.cs#L36-L44
That's not what I'm saying.
I'm saying don't expose Kestrel to the internet, with TLS or not. That's not what we recommend. Always run it behind a proxy, regardless of needing TLS or not.
So for my internal service to service communications on service fabric or self host can I use kestrel and is TLS supported in that scenario?
Also FYI there seems to be lots of conflicting information here.
If you are deploying to a standard Azure SF cluster your microservices are deployed to VM scale sets and the whole cluster lives inside its own Virtual Network.
The microservices communicate with each other over the Virtual Network so they are not open to the outside world - here you can use Kestrel without a proxy as there should be no way to directly contact those services from outside the Virtual Network.
If you additionally wish to add SSL to these communications on top of the isolation that the Virtual Network provides for full end-to-end encryption then you want to use the Microsoft.AspNetCore.Server.Kestrel.Https
package as shown in the samples.
However, you will also likely have one or more ports open via the load balancer to the outside world to a stateless service that acts as the gateway to your cluster.
Here you should either use a reverse proxy to the stateless service (e.g. insuring the IIS role is installed on the server etc) or more straight-forwardly use WebListener (see announcement) instead of Kestrel for these ports.
It should be a fairly simple exchange of UseWebListener
rather than UseKestrel
; but there are more details in the announcement.
Hopefully that is correct @blowdart ?
Addendum
If you are deploying SF with a custom set-up e.g. not to an Azure standard cluster; so a bunch of Azure VMs, AWS, an on premise internal network etc where you are directly setting up the cluster servers/VMs and network; then if the cluster is not on a closed private virtual network you should use WebListener for the inter-service communication as they are open to other things contacting them on their "internal" ports.
This issue was moved to aspnet/Docs#1903
In reading this article it seems to say that it is not. http://aspnetmonsters.com/2016/08/2016-08-07-nginx2/, it seems you need something like nginx or IIS to support SSL in Kestrel .net core.