Secrets often cover some specific aspect of a workload. For example:

  • A Kerberos credential may be bound to one node IP

  • An internal TLS certificate’s subjectAlternateName section must match the Pod object’s name and service

To solve this, the Stackable Secret Operator has a concept of "scopes", which allow a Volume to selectively include this extra context. The exact effect of the scope depends on which backend is used.

Supported Scopes


The node scope is resolved to the name of the Kubernetes Node object that the Pod is running on. This will typically be the DNS name of the node.


The pod scope is resolved to the name of the Kubernetes Pod. This allows the secret to differentiate between StatefulSet replicas.


The service scope allows Pod objects to specify custom scopes. This should typically correspond to Service objects that the Pod participate in.


The listener-volume scope allows Pod objects to request secrets corresponding to a listener volume that is bound to the same Pod.

The listener-volume scope takes the name of the listener volume as a paremeter.


The parameter is the name of the Pod’s volume, not the name of the PersistentVolumeClaim, PersistentVolume, or Listener.


The listener-volume scope also implies the node scope for NodePort listeners.


For example, a TLS certificate provisioned by the autoTls backend, with the scopes node and pod would contain the following values in its subjectAlternateName (SAN) extension field:

  • The node’s IP address

  • The node’s fully qualified domain name (

  • The pod’s fully qualified domain name (