8.7 Best Practices for Sensitive Data
Orbnetes deployment and release orchestration documentation for operators and platform teams.
8.7.1 Keep secrets out of YAML
Never commit credentials directly in blueprint run blocks. Always reference via ${{ secrets.KEY }}.
8.7.2 Use smallest scope possible
Default to environment scope for high-risk credentials. Use project scope only when shared across project environments.
8.7.3 Separate secret and non-secret config
Use secrets for credentials/tokens, and variables for non-sensitive values. This improves auditability and reduces accidental exposure.
8.7.4 Standardize key naming
Use predictable names (for example DB_PASSWORD, API_TOKEN, REGISTRY_URL) to reduce runtime mistakes.
8.7.5 Rotate credentials regularly
Treat project/environment secrets as operational credentials:
- rotate periodically,
- rotate immediately after incident or personnel change,
- verify post-rotation runs.
8.7.6 Restrict management permissions
Only grant secrets/variables management rights to operators who need it. Keep read/update paths auditable.
8.7.7 Validate effective config in lower environments
Before production rollout:
- run blueprint in non-prod with equivalent key set,
- verify missing-key behavior,
- confirm environment selection applies expected values.
8.7.8 Document critical keys per project
Maintain a lightweight key inventory:
- key name,
- scope (global/project/environment),
- owner,
- rotation policy,
- dependent blueprints/jobs.
This turns configuration from ad-hoc state into manageable infrastructure.