Kestrel + .NET Core的推荐标识/用户（Windows）

Question

将Kestrel与IIS一起使用时，您可以定义应用程序池和标识（用户）。 默认标识为“ApplicationPoolIdentity”，但可以是以下之一或自定义用户：

应用程序运行时，Kestrel在IIS中定义的Identity下运行：

但是，当在代理服务器（如nginx（或独立））后面使用Kestrel时，建议的“身份”（用户）使用什么以及如何使用Kestrel？

Answer 1

当您在Windows上的代理后面托管Kestrel时，建议在Windows服务中托管ASP.NET Core应用程序。 Nginx将配置为反向代理应用程序URL（例如http：// localhost：5000 ），ASP.NET应用程序将在服务配置为运行的任何用户下运行。

如果您在Linux上托管，那么您有责任使用底层操作系统提供的任何技术（例如systemd，upstart等）创建自己的服务。

要使用的“推荐”标识取决于ASP.NET应用程序需要访问的资源。 LocalService帐户具有与Users组成员相同的权限。

Answer 2

你似乎在这里感到困惑。 您所谈论的是应用程序池标识（即窗口甚至标记为）。 App Pool本质上是为您的网站提供服务的过程。 进程在帐户下运行，无论是系统，服务，网络还是用户帐户。 该流程运行的帐户确定（显然）它的权限和访问权限。 默认情况下，在IIS中，App Pools在ApplicationPoolIdentity下运行， ApplicationPoolIdentity只是一个本地服务帐户，权限相对有限。

这些都与Kestrel没有任何关系。 Kestrel只是一个简单的Web服务器。 IIS仅用作反向代理。 它接受请求，将它们交给Kestrel，从Kestrel获取响应，然后将该响应发送回客户端。 IIS为您提供安全和管理层，而Kestrel只处理服务请求的繁重工作。

因此，IIS可以替换为几乎任何Web服务器，而不是可以充当反向代理，例如Nginx。 这将以相同的方式工作。 同样，你没有用Kestrel 定义任何东西。 它只是在提供反向代理转发它的请求时咕噜咕噜。 它不知道或不关心反向代理是什么，并不重要。

也就是说，在任何一种情况下都没有“推荐的身份”这样的东西可以使用。 这是您负责做出决定的安全方面。 IIS有一个默认服务帐户，Nginx也可能有一个。 （我没有在Windows上运行Nginx，但是在linux上，它实际上是在nginx:nginx下运行。）对于某些人来说，这很好。 其他人决定使用专用网络帐户或自定义本地服务帐户。 还有一些人决定在实际的用户帐户下运行。 每种选项都有各种各样的原因，没有一种“正确”的方式可以做到这一点，只有一种“正确”的方式适用于您的应用，服务器，网络和组织。 没人能为你做出决定。