将 Kestrel 与 IIS 一起使用时，您需要定义应用程序池和身份（用户）。默认身份是“ApplicationPoolIdentity”，但可以是以下之一或自定义用户：
当应用程序运行时，Kestrel 以您在 IIS 中定义的身份运行：
但是，当在 nginx（或独立）等代理服务器后面使用 Kestrel 时，推荐使用什么“身份”（用户）以及如何将其与 Kestrel 一起使用？
【问题讨论】：
标签： asp.net-core .net-core asp.net-core-2.0 asp.net-core-1.1 kestrel-http-server
当您在 Windows 上的代理后面托管 Kestrel 时，建议在 Windows Service 中托管 ASP.NET Core 应用程序。 Nginx 将被配置为反向代理应用程序 url（例如http://localhost:5000），并且 ASP.NET 应用程序将在服务配置为运行的任何用户下运行。
如果您在 Linux 上托管，那么您有责任使用底层操作系统提供的任何技术（例如 systemd、upstart 等）创建自己的服务
要使用的“推荐”标识取决于 ASP.NET 应用程序需要访问的资源。 LocalService 帐户与 Users 组的成员具有相同的权限。
【讨论】：
您似乎在这里感到困惑。您正在谈论的是应用程序池标识（窗口甚至被标记为）。应用程序池本质上是为您的网站服务的过程。进程在帐户下运行，可以是系统、服务、网络或用户帐户。该进程在哪个帐户下运行（显然）决定了它的权限和访问权限。默认情况下，在 IIS 中，App Pools 运行在ApplicationPoolIdentity 下，这只是一个本地服务帐户，权限相对有限。
这一切都与 Kestrel 无关。 Kestrel 只是一个简单的 Web 服务器。 IIS 仅充当反向代理。它接受请求，将它们交给 Kestrel，从 Kestrel 获取响应，然后将该响应发送回客户端。 IIS 为您提供安全和管理层，而 Kestrel 只处理处理请求的繁重工作。
因此，IIS 可以与几乎任何可以充当反向代理的 Web 服务器互换，例如 Nginx。这将以相同的方式工作。同样，您没有定义 Kestrel 的任何内容。它只是在为反向代理转发它的请求提供服务时发出咕噜声。它不知道也不关心那个反向代理是什么，也没关系。
也就是说，在任何一种情况下，都没有“推荐的身份”之类的东西可以使用。这是您负责做出决定的安全方面。 IIS 有一个默认服务帐户，Nginx 可能也有一个。 （我没有在 Windows 上运行 Nginx，但在 linux 上，它确实在 nginx:nginx 下运行。）对于某些人来说，这很好。其他人决定使用专用网络帐户或自定义本地服务帐户。还有一些人决定在实际用户帐户下运行。每个选项都有各种原因，没有一种“正确”的方法可以做到这一点，只有一种适用于您的应用程序、服务器、网络和组织的“正确”方法。没有人可以为您做出这些决定。
【讨论】：