如何通过Terraform结合gMSA认证实现Windows DNS更新自动化？

核心思路 #

由于Azure DevOps构建服务已以gMSA身份在对应服务器上运行，Terraform可直接继承该进程的Windows身份，通过SSPI机制自动完成Kerberos认证，无需配置密码或keytab。

前置验证 #

• 确认dns_prod_gmsa已被授权修改dns_prod_server的DNS记录（dns_dev_gmsa同理），可通过DNS管理器的Zone安全设置验证权限。
• 确认dns_prod_build_server上的Azure DevOps构建服务确实以dns_prod_gmsa身份运行（通过服务管理器查看服务的“登录身份”）。

配置方案 #

方案1：使用Microsoft官方Windows DNS Provider #

该Provider专为Windows DNS设计，天然支持Windows身份认证：

terraform {
  required_providers {
    windowsdns = {
      source  = "microsoft/windowsdns"
      version = ">= 0.1.0"
    }
  }
}

# 生产环境DNS Provider配置
provider "windowsdns" {
  server = "dns_prod_server"
  # 无需配置凭据，自动继承运行进程的gMSA身份
}

# 示例：创建A记录
resource "windowsdns_a_record" "prod_test" {
  zone_name     = "your-domain.com"
  name          = "prod-test"
  ipv4_address  = "10.0.0.10"
  ttl           = 300
}

方案2：使用HashiCorp通用DNS Provider #

通用DNS Provider支持DNS UPDATE协议，可借助Windows Kerberos身份完成认证：

terraform {
  required_providers {
    dns = {
      source  = "hashicorp/dns"
      version = ">= 3.0.0"
    }
  }
}

# 生产环境DNS Provider配置
provider "dns" {
  update {
    server = "dns_prod_server"
    # 无需配置keyfile或用户名密码，依赖进程的Kerberos身份
  }
}

# 示例：创建A记录集
resource "dns_a_record_set" "prod_test" {
  zone      = "your-domain.com"
  name      = "prod-test"
  addresses = ["10.0.0.10"]
  ttl       = 300
}

关键注意事项 #

• 确保构建服务器与DNS服务器之间的53端口（UDP/TCP）连通，DNS UPDATE操作依赖TCP协议。
• 若遇认证失败，可在构建服务器上执行klist命令，检查是否存在针对DNS服务器的Kerberos票据。
• 禁止在Provider配置中硬编码任何凭据，完全依赖进程身份确保安全性。

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