Scope

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

node

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.

pod

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

service

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

listener-volume

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.

note

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

note

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

Example

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 (my-node.example.com)

  • The pod’s fully qualified domain name (my-pod.my-service.my-namespace.svc.cluster.local)