You can use Downward API to expose Pod fields to containers: https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/

On a related note, if you do not rely on automatically injected env vars for service discovery then you may find it useful to reduce number of env vars in your containers with enableServiceLinks set to false.

Docs: kubectl explain deployment.spec.template.spec.enableServiceLinks

EnableServiceLinks indicates whether information about services should be injected into pod's environment variables, matching the syntax of Docker links. Optional: Defaults to true.

Which secrets are used as values of environmental variables can be seen in the pod's configuration, including for currently running pods. For more info:

https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables

Your pod needs to talk to the api server and ask for the pod definition, to be able to find it.

For that, pod's service account (be it default or a custom one) needs the appropriate Role and RoleBinding that allows that service account to read certain kubernetes resources, in this case, the pod definition itself, and probably the Secret objects in the namespace, so it can find out the corresponding secret (i.e. if there is an environment variable that is coming from a secret via envFrom directive).

The service account token is mounted to the path /var/run/secrets/kubernetes.io/serviceaccount/token in a pod. Using that token, your process can talk to the Kubernetes api from inside the cluster. You can use any Kubernetes client library in any language, or simply kubectl. Then it's a matter of implementing the logic that will find out which secrets are providing which files/variables.

As described by community:

1. If secrets were mounted as Using Secrets as Environment Variables You an display all of them from within using information from documentation:

 env | grep SECRET
 echo $SECRET_your_key
 echo $SECRET_PASSWORD $SECRET_USERNAME

2. If you are interested with "Accessing the API from a Pod"

• you can use kubectl, Directly accessing the REST API or directly call api-server f.e.:

• curl -sSk -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default:443/api/v1/namespaces/default/secrets/your_secret

• curl -v --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default:443/api/v1/namespaces/default/secrets/

If you got the error like: system:serviceaccount:default:default" cannot list resource "secrets" in API group "" in the namespace "default please refer to:

RBAC Authorization create role/rolebinding

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: default-role
rules:
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - get
  - list

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-deafult-role
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: default-role
subjects:
- kind: ServiceAccount
  name: default

Please let me know if it helps.