Replace secretName with a secrets array on postgreSqlDatabases and mySqlDatabases

[willdavsmith]

Description

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
    ]
  }
}

The mySqlDatabases change is identical in shape (same secrets array, same annotation, same required update).

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>}}, where <secretName> is the secret resource's name and <key> is a key in its data. Platform recipes therefore consume real credentials without the developer ever placing them in the app definition.

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, …). A list of resource IDs handles that; a single magic name string does not.
• Consistent with connections. Developers already reference other resources by .id; secrets now follow the same convention.
• Namespaced, collision-free. Recipe references are qualified by secret name (...secrets.<secretName>.<key>), so multiple bound secrets never clash.

required is updated from [environment, secretName] to [environment, secrets] on both types. This is a metadata + schema-shape change to one existing property; the types' recipes are otherwise unchanged.

Important

This depends on the engine support added in radius-project/radius#12254, which introduces the x-radius-secret-binding annotation and the {{context.resource.secrets.<secretName>.<key>}} resolution path. The annotation is inert on engine versions without it, so this PR stays a draft until #12254 lands. Design context: radius-project/radius#12244.

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

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 / mySqlDatabases resource whose secrets array points at a Radius.Security/secrets resource, and proves the injected secret value reaches the cloud database (the server's administratorLogin read-back matches the secret's username), 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

_{Remaining checklist items (README docs, developer documentation, recipe authoring/idempotency, rad resource-type show) are unchanged from main — this PR only changes a single property's shape on two existing types.}

[github-actions]

Dependency Review

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

Scanned Files

None

[willdavsmith]

Superseded by #197, which consolidates the secrets array change with the new x-radius-retain annotation on Radius.Security/secrets into a single draft PR. Closing in favor of #197.