GitLab CI/CD掩码受保护变量导致AWS部署失败如何解决

• 受保护（Protected）属性的GitLab CI变量存在生效范围限制：这类变量仅会注入到运行在受保护分支、受保护标签上的流水线作业中，如果部署作业是在非保护分支、未受保护标签、手动触发的非保护分支流水线中运行，两个AWS密钥变量根本不会被传递到amazon/aws-cli容器内，AWS CLI读取不到有效密钥自然返回安全令牌无效的错误。
• 掩码（Masked）属性的GitLab CI变量存在格式校验规则：如果变量值包含换行、空格、Shell特殊转义字符，或者长度不符合掩码要求，变量注入时会被自动截断、替换为空值，导致传入AWS CLI的密钥信息错误。
• 原有配置手动执行aws configure set写入密钥，额外多了一层本地配置文件写入的步骤，容易因为容器内权限、变量转义问题导致密钥写入异常。

1. 调整受保护变量的生效范围
   进入项目的设置-仓库-受保护分支页面，将运行部署作业的分支（比如main、生产环境分支）添加为受保护分支，给触发部署流水线的对应角色开放所需权限；如果是定时任务、手动触发的流水线，也要确认触发关联的分支属于受保护分支，确保受保护变量可以正常注入作业环境。
2. 校验掩码变量格式
   GitLab掩码变量要求值必须为单行、长度在8-10000字符之间，不能包含空格、换行、特殊转义符号。你可以临时在script段加长度校验逻辑（校验完记得删除，不要直接打印密钥明文避免泄露）：

   - echo "AK长度: ${#AWS_ACCESS_KEY_ID}, SK长度: ${#AWS_SECRET_ACCESS_KEY}"
   

   如果输出的长度和你实际保存的密钥长度不一致，说明变量被掩码规则拦截，检查密钥复制时是否带入了多余的换行、空格，修正后再重新保存变量即可。
3. 优化CI配置，改用AWS CLI原生环境变量鉴权
   AWS CLI原生支持直接从系统环境变量读取鉴权信息，不需要手动执行aws configure set写入配置文件，能避免配置写入、转义带来的异常，修改后的配置如下：

   deploy:
     stage: deploy
     image:
       name: amazon/aws-cli:latest
       entrypoint: [""]
     variables:
       AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
       AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
       AWS_DEFAULT_REGION: $AWS_DEFAULT_REGION
     script:
       - aws --version
       - aws lambda update-function-code --function-name lambda-function --zip-file fileb://"$CI_PROJECT_NAME".zip
   

在受保护分支上触发流水线，先通过长度校验确认变量值长度符合预期，再移除调试代码执行部署作业即可正常运行。注意不要在流水线日志中直接打印密钥明文，避免密钥泄露。

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