feat: add Gitleaks config and CI workflow

[stevefulme1]

Summary

• Adds .gitleaks.toml with default rules extended by custom Ansible-specific credential detection patterns (OpenShift API keys, Automation Hub tokens, container registry passwords)
• Configures allowlists for placeholder values (changeme), Jinja2 template variables ({{ }}), Ansible Vault references, example domains, and YAML comments
• Adds path-based allowlists for defaults/main.yml and inventory.yml where variable declarations use block scalar indicators
• Adds .github/workflows/gitleaks.yml GitHub Actions workflow to run Gitleaks on pushes to main and all PRs
• Complements the existing Gitleaks pre-commit hook in .pre-commit-config.yaml

Related

• Resolves: MFG-376

Test plan

• Verify gitleaks detect --config .gitleaks.toml --no-git reports no false positives on the current codebase
• Verify the GitHub Actions workflow triggers on PR creation
• Test that a commit containing a real secret (e.g., a test API key) is detected and flagged
• Confirm pre-commit hook still works with the new config file

🤖 Generated with Claude Code

[sabre1041]

@luizfao @jeffcpullen Would you be able to review the content of this PR?

[jeffcpullen]

Not an expert it GitHub actions or Gitleaks, but it looks like what I would expect to see. I appreciate the carve out on specific files with specific criteria "changeme" password placeholders. Going to let this run to review the output.

[jeffcpullen]

Ok, the run failed with 11 false positives.

10 of the 11 were looking at README.md files that do not contain secrets, but instead are documenting variables. For example, this line triggered Gitleaks.

<b>vm_ssh_openshift_api_key:</b> OpenShift API Key

The last one triggered the 'create_mf_aap_token_openshift_api_key' variable becuase it uses a multi-line YAML format.

    - name: Set fact with Service Account API key
      ansible.builtin.set_fact:
        create_mf_aap_token_openshift_api_key: >-
          "{{ create_mf_aap_token_migration_factory_aap_sa_token.resources[0].data.token | b64decode }}"
      no_log: "{{ create_mf_aap_token_secure_logging }}"

[stevefulme1]

@jeffcpullen Thanks for running it and flagging those! I've pushed a fix (deaa285) that resolves all 11 false positives:

Changes to .gitleaks.toml:

1. Added README.md to the global path allowlist — these files contain docsible-generated variable documentation (e.g., <b>vm_ssh_openshift_api_key:</b> OpenShift API Key), not actual secrets
2. Added <b>.*</b> regex allowlist — catches the HTML bold tag pattern used to document variable names in READMEs
3. Added [>|][+-]?\s*$ regex allowlist — catches multi-line YAML block scalars (>-, |, etc.) where the value is a Jinja2 template on the following line (e.g., create_mf_aap_token_openshift_api_key: >-)
4. Extended per-rule path allowlists — added README.md and tasks/main.yml to the openshift-api-key and container-registry-password rules

Verified locally: gitleaks detect --config .gitleaks.toml -v now returns 0 leaks across all 43 commits.

[sabre1041]

LGTM

[burigolucas]

The new gitleaks workflow add two changes to the current secret scanning in the pre-commit and CI workflows:

1. It performs a full git history scanning not done in the other workflows
2. Uses a customization to the gitleaks config that extends the default configuration

The advantage of adding this workflow is the clear separation of concerns. This new workflow will provide secret scanning to all PRs (internal and from forks) without the need of manual approving as in the case of the CI workflow.

We should then consider whether we need to use the same gitleaks configuration to the other workflows as well.

[stevefulme1]

@burigolucas The CI failure on ansible-validate-tokens (run #26514770755) is a missing AUTOMATION_HUB_TOKEN secret in repo settings — not a code issue.

AUTOMATION_HUB_TOKEN is not defined. Exiting

Could you (or a repo admin) add the AUTOMATION_HUB_TOKEN secret under Settings → Secrets and variables → Actions?

[burigolucas]

The root cause is not that. The token is defined but it is not available to the pull_request event for security reasons. The CI must run through the pull_request_target event that we must manually approve first. I will do it once I am back to the keyboard