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.

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)