Track dotnet-monitor and OneLoc GitHub App credentials

[missymessa]

Tracks both GitHub App credentials in the EngKeyVault Secret Manager manifest using the established github-app-secret type:

• dotnet-monitor-release-app
• oneloc-localization-app

Each declaration manages the App ID and private key, records the GitHub App name as Secret Manager metadata during interactive setup, schedules rotation every six months, and supports emergency rotation with secret-manager synchronize --force-secret=<name>.

The existing Key Vault RSA keys remain declared temporarily because the active dotnet-monitor and OneLoc consumers still use az keyvault key sign. They must not be removed until the new composite secrets are populated, both consumers are cut over and validated, and the previous GitHub App keys can be revoked without disrupting releases.

Related work item: https://dev.azure.com/dnceng/internal/_workitems/edit/12318

[Copilot]

Pull request overview

Declares the existing dotnet-monitor-release-app-key RSA key in the EngKeyVault Secret Manager manifest to support the dotnet-monitor GitHub App migration, ensuring the key is tracked/synchronized without generating new key material.

Changes:

• Adds a new RSA (2048-bit) key entry for dotnet-monitor-release-app-key to the EngKeyVault manifest.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟢 Approval recommended

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite

[garath]

This should be tracked as type github-app-secret. I recognize I didn't push for this in the oneloc-localization-app-key but in retrospect I think it's important. Tracking with the strongest secret-manager type gives benefits besides just noting its existence, like the metadata of what bot owns the token, and a well-established path for rotation.

[missymessa]

I checked both keys. oneloc-localization-app-key is in this same Arcade manifest, so these should be handled together.

There is an important incompatibility with changing either declaration directly to github-app-secret:

• Both consumers currently use az keyvault key sign against an Azure Key Vault RSA key (Get-GitHubAppToken.ps1; OneLoc passes oneloc-localization-app-key, and dotnet-monitor passes dotnet-monitor-release-app-key). This keeps the imported private key non-exportable to the pipeline.
• The current Secret Manager github-app-secret implementation creates Key Vault secrets named <name>-app-id and <name>-app-private-key (plus optional OAuth/webhook values), storing the PEM as a retrievable secret. It does not adopt, rotate, or sign with an existing Key Vault key.
• A manifest-only type change would therefore leave the keys actually used by both consumers unmanaged, create differently named unused secrets, and require different RBAC/consumer code. Removing the RSA-key declarations would also allow the used keys to fall outside manifest validation.

I agree that both apps need GitHub-App-specific ownership and rotation metadata. Which model do you want us to standardize on?

1. Preserve Key Vault key-based signing and add/extend a Secret Manager type that tracks GitHub App metadata and rotation for imported Key Vault RSA keys, then convert both declarations together; or
2. Migrate both consumers and service-connection RBAC to the existing PEM-secret-based github-app-secret model as a coordinated change.

I have not made the unsafe manifest-only conversion while this is unresolved.

[garath]

My concerns are:

• trackable metadata, specifically cert owner
• policy-compliant rotations
• a path for "emergency" rotation should the need arise

I'm open to whatever path gets those.

[missymessa]

Implemented the staged github-app-secret path for both apps in 7c3191f:

• Added dotnet-monitor-release-app and oneloc-localization-app as github-app-secret entries with private-key management enabled.
• This records the app name/owner metadata during setup, uses Secret Manager's six-month rotation schedule, and provides the existing --force-secret emergency-rotation path.
• Retained the currently used Key Vault RSA keys as an explicit compatibility layer until the composite secrets are populated and the two consumers are cut over and validated. Removing them in this PR would interrupt the current az keyvault key sign paths.

The manifest validates with the repository's pinned Secret Manager version.

[Copilot]

🔵 Needs a closer look

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite

[missymessa]

@garath want to get your approval on this since you previously had concerns

[Copilot]

🟢 Approval recommended

The change is additive and preserves existing key-based consumers while introducing the new tracked GitHub App secret declarations needed for migration.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite