在GitHub托管Windows Runner中以指定现有AD用户运行GitHub Actions工作流的可行性及实现方案咨询

首先明确说：这个需求是可行的，但因为GitHub托管的Windows Runner是临时一次性环境（每次工作流结束后会彻底重置），所以需要解决几个关键问题，而且每次运行工作流都得重复配置步骤，会有一些额外的操作成本。下面我结合你的场景（需要用AD用户关联的证书和RedTrust）拆解下思路和可能的步骤：

核心前提要先和IT确认 #

在动手之前，得先和IT部门沟通清楚这几个点，不然后续操作大概率卡壳：

• GitHub托管的Runner（公网环境）能不能访问你们公司的AD域控制器？如果你们AD是内网的，可能需要先让Runner通过VPN连接到公司内网，这部分得IT帮忙配置VPN权限和提供连接方式。
• IT是否允许临时的外部机器（GitHub的Runner）加入你们的AD域？或者退一步，是否允许用域用户的凭据在非域机器上执行命令（也就是所谓的「域用户本地登录」）？
• 能不能申请一个专用的服务账户？用来完成加入域、导入证书这类需要权限的操作，别用个人AD账户，安全风险太高。

具体实现的大致步骤 #

假设IT搞定了网络和权限问题，你可以按这个思路来写工作流：

1. 先打通到AD的网络（如果需要）

如果GitHub Runner在公网，你们AD在内网，第一步肯定是连VPN。比如用Windows自带的rasdial命令：

rasdial "你们公司的VPN名称" ${{ secrets.VPN_USER }} ${{ secrets.VPN_PASSWORD }}

这里的VPN账号密码要存在GitHub Secrets里，绝对不能明文写在工作流里。

2. 导入AD用户的证书

因为Runner是全新环境，没有AD用户的配置文件，所以得把用户的证书（带私钥的PFX格式）导入到Runner的证书存储里。你可以先把PFX文件转成Base64字符串存在GitHub Secrets，然后在工作流里还原并导入：

# 从Secrets读取证书内容并保存为本地文件
$certBytes = [System.Convert]::FromBase64String("${{ secrets.AD_USER_CERT_PFX }}")
[System.IO.File]::WriteAllBytes("C:\temp\user-cert.pfx", $certBytes)

# 导入到本地机器的个人存储（这样所有用户都能访问，或者按需导入到当前用户）
Import-PfxCertificate -FilePath "C:\temp\user-cert.pfx" -CertStoreLocation "Cert:\LocalMachine\My" -Password (ConvertTo-SecureString "${{ secrets.CERT_PASSWORD }}" -AsPlainText -Force)

如果RedTrust需要证书在AD用户的个人存储里，那可能需要先创建AD用户的本地配置文件，再导入到对应路径，这个步骤稍微复杂点，需要用reg.exe或者PowerShell的用户配置文件相关命令。

3. 以AD用户身份执行工作流脚本

Windows里直接用runas命令没法自动输入密码，所以推荐用PowerShell的Start-Process结合凭据对象来执行：

# 从Secrets构建AD用户的凭据
$secPass = ConvertTo-SecureString "${{ secrets.AD_USER_PASSWORD }}" -AsPlainText -Force
$adCred = New-Object System.Management.Automation.PSCredential ("你们的域名\${{ secrets.AD_USER_NAME }}", $secPass)

# 以AD用户身份运行你的业务脚本，-Wait确保脚本执行完再继续工作流，-NoNewWindow方便看日志
Start-Process -FilePath "powershell.exe" -ArgumentList "-File .\your-workflow-script.ps1" -Credential $adCred -Wait -NoNewWindow

要注意的坑 #

• Runner的临时性：每次工作流都要重复做VPN连接、证书导入这些步骤，会增加工作流的运行时间，而且如果某个步骤失败（比如VPN连接超时），整个工作流都会失败，建议加一些重试逻辑。
• 权限问题：GitHub Runner默认的runneradmin是本地管理员，能执行大部分操作，但AD相关的操作（比如加入域）需要域管理员权限，这部分必须IT配合。
• 证书安全：带私钥的PFX文件是敏感信息，一定要存在GitHub Secrets里，并且开启Secrets的权限控制，只有必要的人能访问。
• 测试先行：别直接在GitHub Actions里试，先找一台本地的Windows虚拟机，模拟GitHub Runner的环境（全新系统），把整个流程跑通，确认证书和RedTrust都能正常工作，再搬到工作流里。

关于加入AD域的补充 #

如果你的业务必须让Runner加入AD域（比如RedTrust只能识别域用户），那可以用Add-Computer命令加入域，但这里有个问题：加入域后需要重启机器，而GitHub Actions的Job是在一个会话里，重启后会话会中断，所以得用嵌套Job：第一个Job负责加入域并重启，第二个Job在重启后的机器上继续执行。不过这个方案复杂度更高，而且需要IT允许临时机器加入域，一般不推荐，能不用就不用。

总的来说，你的需求是合理的，核心就是解决网络连通、AD权限、证书导入这三个问题，和IT沟通的时候把「临时公网机器需要访问内网AD、用域用户凭据执行命令、导入用户证书」这几个点说清楚，应该能得到他们的支持。

备注：内容来源于stack exchange，提问作者JSalazAlt