Modernize demo sample to Radius.* resource types and add Redis/PostgreSQL variants with secret binding

[willdavsmith]

Summary

Updates the demo sample to the current Radius.* resource types and adds two datastore variants that show how to connect the demo container to a managed cache and database. This mirrors #2645, and additionally applies the Radius secret-binding pattern so credentials are never rendered as plain container env values.

Changes

• samples/demo/app.bicep

  • Migrate from deprecated Applications.* (2023-10-01-preview) to Radius.* (2025-08-01-preview) resource types.
  • Split into a dedicated Radius.Core/applications resource plus a Radius.Compute/containers resource using the new nested containers map schema.
  • Derive environmentName from the Environment ID and suffix resource names (demo-${environmentName}) so multiple environments (dev/test/prod) can coexist in the same resource group without name collisions.

• samples/demo/app-redis.bicep (new)

  • Demo container connected to a Radius.Data/redisCaches cache via a connections.redis link.
  • REDIS_URL is bound from the cache's managed secret with secretKeyRef.

• samples/demo/app-postgresql.bicep (new)

  • Demo container connected to a Radius.Data/postgreSqlDatabases database via a connections.postgresql link.
  • Admin password supplied through a @secure() parameter (never stored in the file), stored in a Radius.Security/secrets resource and bound into the container with secretKeyRef.

Secret handling

Both variants deliberately avoid passing credentials as plain container env values:

• In the Radius Kubernetes containers recipe, a container env entry of the form { value: <string> } is rendered literally into the Kubernetes pod spec and stored unencrypted on the containers resource — the containers resource type schema has no x-radius-sensitive marker on env.value. A secret passed this way is visible to anyone with get pod/describe deployment in the namespace, and via rad resource show.
• By contrast, Radius.Security/secrets marks data.*.value as x-radius-sensitive: true, so Radius encrypts it at rest and redacts it on reads. Binding via env.valueFrom.secretKeyRef keeps the value out of the pod spec and out of container state.
• For redisCaches, the recipe's url secret is already materialized into a managed Radius.Security/secrets resource reachable at redis.properties.secrets.name, so it is bound directly with secretKeyRef.
• For postgreSqlDatabases, the password is a user-supplied input (a @secure() param) and the type exposes no secrets property, so the app creates its own Radius.Security/secrets resource to hand the password to the container.
• We use explicit env + secretKeyRef rather than a second connections entry pointing at the secrets resource: a connection to a Radius.Security/secrets source produces envFrom.secretRef, and Kubernetes does not expand envFrom-sourced variables in $(VAR) references inside container args.

Deploy

rad deploy samples/demo/app.bicep
rad deploy samples/demo/app-redis.bicep
rad deploy samples/demo/app-postgresql.bicep -p password=$(openssl rand -hex 16)

Validation

bicep build was run locally against br:biceptypes.azurecr.io/radius:latest:

• app.bicep — builds clean
• app-postgresql.bicep — builds clean
• app-redis.bicep — fails locally with BCP053: The type "redisCachesProperties" does not contain property "secrets". This is a stale-types issue, not a sample bug: properties.secrets (with the reserved name sub-property, documented for exactly this secretKeyRef binding) is present in Data/redisCaches/redisCaches.yaml in radius-project/resource-types-contrib, but has not yet been republished to the radius:latest bicep type index. The file will build once the types are refreshed.

[github-actions]

Dependency Review

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

Scanned Files

None