ansible-testing/docs/secrets.md

Environment-Specific Secrets

GitLab CI/CD variables are the secret source of record. assets.yml contains only non-secret project, host, and test-profile data.

Environment Selection

Start a pipeline with TARGET_ENVIRONMENT set to the intended GitLab environment scope, for example test, acceptance, or production. The value must exactly match all.vars.test_project.environment in assets.yml.

Tool jobs declare:

environment:
  name: "$TARGET_ENVIRONMENT"
  action: verify

GitLab therefore injects variables matching that environment scope only into tool jobs. Validation and report jobs do not declare an environment and should not receive these credentials.

Configure each secret under Settings > CI/CD > Variables with:

• an exact environment scope such as test or production;
• Protected enabled for protected environments;
• Masked or Masked and hidden where the value format permits it;
• File type for keys, certificates, and structured variable files.

Do not enable CI_DEBUG_TRACE in pipelines that receive secrets.

Ansible Variables

Create ANSIBLE_SECRET_VARS as an environment-scoped File variable. Its contents are an Ansible YAML or JSON variables file, for example:

ansible_user: "DOMAIN\\automation-user"
ansible_password: "replace-in-gitlab"
ansible_become_password: "replace-in-gitlab"
vcenter_username: "automation@vsphere.local"
vcenter_password: "replace-in-gitlab"

The test:ansible job checks that the variable resolves to a file and exports its temporary path as ANSIBLE_VARS_FILE. The methodology runner passes it with --extra-vars @<file> without printing the contents or putting values in the process command line.

For SSH key authentication, add ANSIBLE_PRIVATE_KEY_FILE as a separate environment-scoped File variable. The methodology runner passes that path through --private-key when present.

The current job assumes one credential set per test environment. Environments with distinct Windows, Linux, network, or hypervisor credentials should be split into separate tool jobs, each referencing its own scoped File variable.

ZAP Variables

ZAP authentication will use individually masked variables referenced by its Automation Framework plan, such as ZAP_USERNAME, ZAP_PASSWORD, or ZAP_AUTH_HEADER_VALUE. Define only those required by the selected application. The ZAP adapter and authentication plan are intentionally not enabled yet.

Rotation

Rotate a secret by replacing the value in each GitLab environment scope. No repository change is required. Existing artifacts contain normalized findings, not the GitLab variable files, and the pipeline never uploads secret paths.