Bind Radius.Security/secrets to postgreSqlDatabases and mySqlDatabases, retained at rest

[willdavsmith]

Description

Two related changes that let developers hand secrets to direct-module recipes, consolidated from the previously stacked draft #193:

1. secretName → a secrets array on postgreSqlDatabases and mySqlDatabases

Replaces the single secretName string on Radius.Data/postgreSqlDatabases and Radius.Data/mySqlDatabases with a secrets array annotated x-radius-secret-binding: true. Each entry is the resource ID of a Radius.Security/secrets resource (for example dbSecret.id):

resource postgresql 'Radius.Data/postgreSqlDatabases@2025-08-01-preview' = {
  name: 'postgresql'
  properties: {
    environment: environment
    application: myApplication.id
    size: 'S'
    secrets: [
      dbCredentials.id
    ]
  }
}

Radius recognizes a property carrying this annotation as a list of secret bindings. For every listed secret it loads all of the secret's keys and exposes them to direct-module recipes as {{context.resource.secrets.<secretName>.<key>}}. Platform recipes therefore consume real credentials without the developer ever placing them in the app definition. required is updated from [environment, secretName] to [environment, secrets] on both types.

Why an array of resource IDs instead of a single name string:

• Natural, scalable shape. A database may need more than one secret (credentials, TLS material, …).
• Consistent with connections. Developers already reference other resources by .id.
• Namespaced, collision-free. References are qualified by secret name (...secrets.<secretName>.<key>), so multiple bound secrets never clash.

2. Mark Radius.Security/secrets values x-radius-retain

Adds x-radius-retain: true to the secret value field (already x-radius-sensitive). This keeps the canonical contrib definition in sync with the built-in type: the encrypted value is retained at rest (still redacted on GET/LIST) so recipes can decrypt it from Radius's own store rather than reading a Kubernetes Secret — required for multi-cluster-safe secret resolution.

Important

Depends on the engine support in radius-project/radius (the x-radius-secret-binding resolution path and x-radius-retain persistence). The annotations are inert on engine versions without it, so this stays a draft until the radius change lands. Design context: radius-project/radius#12244.

Related GitHub Issue: N/A (tracked in radius-project/radius#12244)

Testing

Exercised end-to-end by the manual resource-type verification workflow in radius-project/resource-types-verification — the Azure (Bicep AVM) direct-module flow registers each manifest, deploys a postgreSqlDatabases resource whose secrets array points at a Radius.Security/secrets resource, and proves the injected secret value (retained encrypted at rest, decrypted from Radius's store) reaches the real Azure database, then validates delete.

Contributor Checklist

• File names follow naming conventions and folder structure
• All properties in the Resource Type definition have clear descriptions
• Required properties are listed in required: [] for every object property
• Properties about the deployed resource are defined as read-only (readOnly: true)
• Resource types and recipes were tested

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None