Azure Container中使用.htaccess实现密码验证方案咨询

现有思路的可行性判断 #

.htaccess是Apache HTTP Server专属的分布式配置文件，是否生效和Azure Container服务本身无关，完全取决于你容器内部运行的Web服务类型：

• 若容器内使用Apache作为Web服务器，你的配置逻辑方向正确，但存在3个必须修正的问题，否则会直接失效或报服务错误：
  • AuthUserFile参数不能写容器根路径/.htpasswd，必须填写.htpasswd文件在容器内的真实绝对路径。比如通常Apache站点根目录为/var/www/html，建议把.htpasswd放在站点目录外避免被公网下载，对应路径可写为/etc/apache2/.htpasswd，路径错误会直接触发500错误。
  • 提前确认所用Apache镜像已启用mod_auth_basic、mod_authn_file、mod_authz_user三个认证相关模块，部分精简版Apache镜像默认未加载这些模块，会导致配置不生效。
  • 不要把.htpasswd放在Web可访问的站点目录下，防止密码哈希文件被外部直接下载。
• 若容器内运行的是Nginx、Caddy、Node.js原生服务、其他非Apache类Web服务，.htaccess配置完全不会被识别，这个方案不可用。

该场景下弹窗式身份验证的更优实现 #

你当前把认证逻辑耦合在业务容器内部Web服务的方案，并不是Azure Container环境下的最优选择，以下方案不需要改动业务容器内部配置，同样可以触发浏览器原生的账号密码输入弹窗，维护成本更低：

• 若使用Azure Container Apps（容器应用）服务：直接启用服务内置的入口身份验证能力，在平台层配置路径匹配规则，仅对你指定的几个html文件开启Basic认证即可，认证逻辑由Azure平台侧处理，不需要往容器内上传配置、修改服务参数，后续还可以平滑切换到Azure AD等企业级身份源。
• 若使用Azure Container Instances（ACI容器实例）：可以在业务容器旁部署反向代理侧车容器，或者前置应用网关，在反向代理/网关层配置Basic认证规则，完全不需要改动原有业务容器的内容。

适配Apache场景的配置修正参考 #

如果你确定容器内使用Apache作为Web服务，修正后的.htaccess配置如下：

<FilesMatch "^(index|standalone|standalone-async|spa)\.html$">
    AuthName "Dialog prompt"
    AuthType Basic
    # 请替换为你容器内.htpasswd文件的实际绝对路径
    AuthUserFile /etc/apache2/.htpasswd
    Require valid-user
</FilesMatch>

配置部署完成后，可进入容器执行apache2ctl configtest（Debian/Ubuntu基础镜像）或httpd -t（CentOS/RHEL基础镜像）校验配置语法，避免服务启动异常。

内容的提问来源于stack exchange，提问作者Joris Fonck