Terraform修改SSH公钥时重建default安全组报错排查

• 优先核对Terraform状态一致性：Terraform对资源的增删改判断完全基于本地/远端状态文件与当前配置的比对结果，你本次修改的SSH公钥配置与安全组资源无任何依赖关联，正常逻辑下不可能触发安全组重建，最高概率的诱因是状态文件中aws_security_group.default的资源记录丢失。常见触发场景包括：有人手动执行过terraform state rm aws_security_group.default未回滚、远端状态存储（如S3、GCS）被回退到该资源创建前的版本、多环境状态文件路径配置错误串了环境。
• 检查安全组资源配置是否被隐式修改：核对最近的配置提交，确认是否存在两类误改：一是将原本用于管理AWS默认安全组的aws_default_security_group资源类型误改成普通aws_security_group资源，Terraform会将不同类型的同名资源识别为全新资源；二是安全组的name参数被误设置为default——AWS中default是VPC默认安全组的保留名称，不允许用户通过普通安全组创建接口新建同名资源。
• 核对运行环境版本一致性：检查CI/CD执行Terraform命令的环境，确认Terraform核心版本、AWS Provider版本与此前正常运行的版本无差异，部分大版本升级可能存在默认安全组识别逻辑的兼容问题。

1. 先验证状态缺失问题：执行以下命令检查状态中是否存在对应安全组记录

   terraform state list | grep aws_security_group.default
   

   如果命令无返回结果，即可确认状态记录丢失。先登录AWS控制台找到对应VPC下的目标安全组，复制其ID，执行导入命令将现有资源补入状态：

   terraform import aws_security_group.default <替换为实际安全组ID>
   

   导入完成后重新执行terraform plan，确认不再出现新建安全组的提示即可。
   注意：如果配置中原本使用aws_default_security_group资源管理默认安全组，导入时需匹配正确的资源类型，不要导入到普通aws_security_group资源下。
2. 如果状态中存在对应资源记录，直接修正配置问题：
   • 若资源类型被误改，回滚为正确的资源类型：管理VPC默认安全组必须使用aws_default_security_group资源，无需手动指定name参数（该名称为AWS固定保留值），修正后重新执行plan验证。
   • 若name参数被误设为default且你要管理的是自定义安全组，将name修改为非保留值即可。
3. 若排查确认是版本兼容问题，将Terraform核心、AWS Provider回滚到此前稳定运行的版本，执行terraform init -upgrade=false重新初始化工作目录后再验证plan结果。

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