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

listener-volume

Syntax: listener-volume=<VOLUME> (for example: listener-volume=my-listener)

The listener-volume scope is resolved according to a Listener.

The Listener should be mounted as a volume alongside the Secret volume, and takes the name of that volume as its parameter. This way, the scope will automatically adapt to the ListenerClass that it uses.

Multiple Listeners can be bound by specifying the scope multiple times.

note

The parameter is the name of the Pod’s volume, not the name of the PersistentVolumeClaim, PersistentVolume, or Listener. This allows the scope to bind to replica-specific or ephemeral Listeners.

pod

Syntax: pod

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

node

Syntax: 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.

Consider using the xrerf:#listener-volume[] scope instead, which also allows the scope to automatically adjust to how the Pod is exposed.

service

Syntax: service=<SERVICE> (for example: service=my-service)

The service scope is resolved to an arbitrary Kubernetes Service in the same Namespace.

This scope only supports cluster-internal (ClusterIP) Services. Consider using the listener-volume scope instead.

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)