# 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:

```yaml
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:

```yaml
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.