Align Kubernetes postgreSQL recipe secret handling with Azure

The Kubernetes recipe returned `secrets: { password, connectionString }`, but
the postgreSqlDatabases type declares no `secrets` property, so neither value
was reachable from an application. The Azure recipe in
recipe-packs/azure/aks-recipepack.bicep maps only `host`, and deliberately does
not use the `outputs.secrets` mechanism it uses one entry away for redisCaches.

That distinction is intentional. PostgreSQL administrator credentials flow into
the recipe as user-supplied properties, so there is nothing to hand back; Redis
access keys are generated by the infrastructure and must flow out. Drop the
unreachable secrets output so both platforms agree, and document the reasoning.

Also emit `port` as a string to match `type: string` on the resource type, and
update test/app.bicep to show the supported pattern: the application authors its
own Radius.Security/secrets resource and binds it into the container with
valueFrom.secretKeyRef. A connection cannot carry the password (sensitive
properties redact to null and are skipped by the containers recipe), so this is
the only way to deliver it, and it keeps the value out of the pod spec and off
the container resource, where env values are stored unencrypted.

Signed-off-by: Will Smith <willdavsmith@gmail.com>

Author: willdavsmith

Data/postgreSqlDatabases/recipes/kubernetes/bicep/kubernetes-postgresql.bicep

@@ -188,7 +188,16 @@ resource svc 'core/Service@v1' = {
 }
 
 //////////////////////////////////////////
-// Output Radius result 
+// Output Radius result
+//
+// No `secrets` output: the administrator credentials flow *into* this Recipe as
+// user-supplied properties, so there is nothing for the Recipe to hand back. An
+// application that needs the password for a consuming container already holds it
+// and should author its own Radius.Security/secrets resource, binding it with
+// `valueFrom.secretKeyRef` (see test/app.bicep). This matches the Azure recipe in
+// recipe-packs/azure/aks-recipepack.bicep, which maps only `host`. Contrast with
+// redisCaches, where the access key is generated by the infrastructure and so is
+// returned via `outputs.secrets`.
 //////////////////////////////////////////
 
 output result object = {
@@ -204,11 +213,8 @@ output result object = {
   )
   values: {
     host: '${svc.metadata.name}.${svc.metadata.namespace}.svc.cluster.local'
-    port: port
+    // `port` is declared `type: string` on the Resource Type, so emit a string.
+    port: string(port)
     database: database
   }
-  secrets: {
-    password: password
-    connectionString: 'postgresql://${username}:${password}@${svc.metadata.name}.${svc.metadata.namespace}.svc.cluster.local:${port}/${database}'
-  }
 }

Data/postgreSqlDatabases/test/app.bicep

@@ -3,17 +3,35 @@ extension radius
 @description('The ID of your Radius Environment. Set automatically by the rad CLI.')
 param environment string
 
-@description('Database admin password. Set on the resource `password` property (x-radius-sensitive), so Radius encrypts it at rest and injects it decrypted into the Recipe as the flexible server administrator password.')
+@description('Database admin password. Set on the `password` property of the database (x-radius-sensitive, so Radius encrypts it at rest and injects it decrypted into the Recipe) and stored in a Radius.Security/secrets resource for the consuming container to bind by reference.')
 @secure()
 param password string
 
 resource app 'Radius.Core/applications@2025-08-01-preview' = {
-  name: 'postgresql-azure-test'
+  name: 'postgresql-test'
   properties: {
     environment: environment
   }
 }
 
+// The password is also needed by the consuming container. Store it in a
+// Radius.Security/secrets resource rather than passing it to the container as a
+// plain `env` value: `data.value` is x-radius-sensitive (encrypted at rest,
+// redacted on reads), whereas a container `env.value` is stored unencrypted on
+// the container resource and rendered literally into the Pod spec.
+resource dbCreds 'Radius.Security/secrets@2025-08-01-preview' = {
+  name: 'postgresql-credentials'
+  properties: {
+    environment: environment
+    application: app.id
+    data: {
+      password: {
+        value: password
+      }
+    }
+  }
+}
+
 resource postgresql 'Radius.Data/postgreSqlDatabases@2025-08-01-preview' = {
   name: 'postgresql'
   properties: {
@@ -34,6 +52,20 @@ resource democontainer 'Radius.Compute/containers@2025-08-01-preview' = {
     containers: {
       demo: {
         image: 'ghcr.io/radius-project/samples/demo:latest'
+        // Host, port, and database arrive automatically as
+        // CONNECTION_POSTGRES_* env vars from the connection below. Only the
+        // password needs wiring, and it is bound by reference so the value
+        // never lands in the Pod spec or on this container's state.
+        env: {
+          POSTGRES_PASSWORD: {
+            valueFrom: {
+              secretKeyRef: {
+                secretName: dbCreds.name
+                key: 'password'
+              }
+            }
+          }
+        }
         ports: {
           web: {
             containerPort: 3000