CompTech AIOps - GitHub secret custody

How comptech-aiops uses GitHub secrets instead of Vault for the current phase.

The current decision is to use GitHub as the secret custody system for comptech-aiops. Vault is not part of the first phase.

This is a deliberate tradeoff. GitHub secrets work well for workflow-driven automation and restore operations. They are not a general interactive password vault. The recovery model is therefore not “open a vault and copy the password”; it is “run an approved workflow that materializes the secret onto a target machine or deployment environment.”

Governing Decision

Current Secret Registration

The token value was copied into GitHub without printing it and verified only by secret name metadata.

Secret Handling Rules

• Store real values only in GitHub secrets.
• Do not commit .env files with real values.
• Do not publish local secret source paths.
• Do not print secrets in workflow logs.
• Use uppercase, underscore-separated secret names.
• Prefer environment secrets for deployment-specific values.
• Prefer dedicated service credentials over personal credentials.
• Rotate a secret after accidental exposure.

Restore Model

A future restore workflow should do this:

1. Require approval through a protected GitHub environment.
2. Pull the declarative repo state.
3. Inject required GitHub secrets into the workflow runtime.
4. SSH or otherwise authenticate to the target machine.
5. Write root-owned runtime files such as /etc/comptech-aiops/*.env.
6. Deploy declarative Compose, systemd, or other desired-state definitions.
7. Validate the running service.

The workflow should show secret names, target paths, and validation results. It should never show secret values.

Boundary

GitHub may hold secrets. Git may hold only references, examples, and inventory metadata.

Good:

CLOUDFLARE_API_TOKEN is required by the Cloudflare deployment workflow.

Bad pattern:

Do not publish the Cloudflare token value in docs, issues, PRs, logs, or changelogs.