The short answer is that I think it doesn't let you see a secret but use a reference where you want to use it: Deployments, StatefulSets, DaemonSets, Pods, etc. It would make sense from the security point of view.

You can see an example of create a secret here

Use k8s.core.v1.Secret.get(pulumiName, secretName) (secretName can contain the namespace/ as prefix).

Every Pulumi resource has a get() method.

For example: Get the token from a kubernetes.io/service-account-token:

import * as k8s from "@pulumi/kubernetes";
​
type KubernetesSecretData = { [key: string]: string }
​
const namespace = 'kube-public'
const secretName = 'default-token-tdcdz'
​
export const token =
    k8s.core.v1.Secret.get('testSecret',`${namespace}/${secretName}`)
        .data.apply(v => {
        return (<KubernetesSecretData> v)["token"]
    })

That API looks like it mirrors the Kubernetes API, and in particular there is a core/v1.Secret object that includes the secret data. The values are base64-encoded.

(Unless RBAC forbids it, you can generally kubectl get secret -o yaml secretname to see the same thing...Kubernetes secrets are only so secret.)

If you're running this in the context of a service it's probably easier to launch the service with environment variables set from the relevant secret values, using a YAML fragment like

env:
- name: SECRET_USERNAME
  valueFrom:
    secretKeyRef:
      name: test-secret
      key: username