Feature Overview (aka. Goal Summary)

Red Hat Developer Hub (RHDH) currently relies on static environment variables or manual input for sensitive data during the software templating process. This feature aims to integrate RHDH with external secret management providers (such as HashiCorp Vault, Azure Key Vault, and OpenShift Secrets) to dynamically inject credentials, tokens, and keys into the Scaffolder at runtime.

By enabling this integration, we reduce the risk of secret leakage, eliminate manual hand-offs of sensitive data, and ensure that Platform Engineering teams can enforce centralized security policies across all automated scaffolding workflows.

Goals (aka. expected user outcomes)

• Improved Security Posture: Sensitive data is never stored within RHDH or hardcoded in software templates; it is fetched JIT (Just-In-Time) and injected into the workspace.

• Operational Efficiency: Developers no longer need to manually fetch or input API tokens or SSH keys when creating new projects; the portal handles this automatically via authenticated backend calls.

• Centralized Governance: Security teams can rotate secrets in their provider of choice (e.g., HashiCorp Vault) without breaking RHDH templates, as the portal always pulls the "current" version.

Requirements (aka. Acceptance Criteria):

• As a Platform Engineer, I want to configure multiple secret provider backends in the app-config.yaml, so that RHDH has the necessary permissions to communicate with our enterprise vault solutions.
• As a Platform ** Engineer{}, I want all secret retrieval attempts to be masked in the Scaffolder logs, ensuring that no sensitive values are exposed in the RHDH UI or audit trails.

• As a Template Author, I want to use a specific syntax (e.g., ${{ secrets.vault.my-secret-key }}{}) within my template.yaml definitions, so that the Scaffolder knows which external secret to fetch during execution.

• As a Developer, I want the scaffolding process to automatically inject these secrets into actions (like publish:github or fetch:template), so that I don't have to manually provide credentials I may not have access to.

Out of Scope

• Secret Writing/Creation: This feature focuses solely on reading secrets for use in templates. Creating or updating secrets in external vaults via RHDH is out of scope for this phase.
• User-Level Vault Permissions: Initial implementation will likely use a "Service Account" pattern where RHDH acts as the identity, rather than impersonating the end-user's specific vault credentials.

Customer Considerations

• Network Connectivity: Large organizations often place Vaults behind strict firewalls. RHDH must be able to reach these endpoints via configured proxies if necessary.

• Authentication Methods: Support for multiple auth methods (AppRole, Kubernetes Auth, Azure Managed Identity) is critical for enterprise adoption.

• Latency: Fetching secrets at runtime adds overhead. The implementation should include reasonable timeouts and error handling if a provider is unreachable.

Documentation Considerations

• Configuration Guide: Detailed steps on how to enable the secrets backend and specific configuration snippets for HashiCorp, Azure, and OpenShift.

• Template Authoring Reference: Clear examples of the YAML syntax required to reference external secrets within a Scaffolder template.

• Security Best Practices: Guidance on least-privilege access for the RHDH service account within the secret providers.