Volume

The primary entry point for applications is by mounting a secret into a Pod object’s volume set. This is done by using Kubernetes' EphemeralVolumeSource type. For example:

---
apiVersion: v1
kind: Pod
metadata:
  name: example-secret-consumer
spec:
  volumes:
    - name: secret
      ephemeral:
        volumeClaimTemplate:
          metadata:
            annotations:
              secrets.stackable.tech/class: secret (1)
              secrets.stackable.tech/scope: node (2)
          spec:
            storageClassName: secrets.stackable.tech (3)
            accessModes: (4)
              - ReadWriteOnce
            resources: (4)
              requests:
                storage: "1"
  containers:
    - name: ubuntu
      volumeMounts:
        - name: tls (5)
          mountPath: /tls

1	This secret is provided by the `SecretClass` named `tls`
2	This secret should be scoped by the intersection of `node`, `pod`, and the `service` named `secret-consumer`
3	Tells Kubernetes that the Stackable Secret Operator is responsible for mounting this volume
4	Kubernetes requires us to specify some boilerplate settings for a `PersistentVolumeClaim` to be well-formed
5	The injected volume can then be mounted into a container, just like any other volume. In this example, the secrets are provided in the `/tls` directory of the container.

Only ephemeral volumes are supported, the Secret Operator does not support declaring standalone PersistentVolumeClaim objects.

Attributes

`secrets.stackable.tech/class`

Required: true

Backends: All

The name of the SecretClass that is responsible for providing this secret.

`secrets.stackable.tech/scope`

Required: false

Default value: no scopes

Backends: All

The scopes used to select or provision the secret. Multiple scopes should be separated by commas (,), and scope parameters are separated by equals signs (=) where applicable.

`secrets.stackable.tech/format`

Required: false

Default value: default format of backend

Backends: All

The format that the secret should be written as.

This can be either the default output format of the backend, or a format that it defines a conversion into.

`secrets.stackable.tech/backend.autotls.cert.lifetime`

Required: false

Default value: 1d

Backends: secretclass.adoc#backend-autotls

The lifetime of the created certificate. Please note that you can not request a lifetime longer than allowed by maxCertificateLifetime on the SecretClass. If you do so, maxCertificateLifetime will be used as the certificate lifetime, to adhere to the requirements set by the administrator who created the SecretClass.

The format is documented in Duration format.

`secrets.stackable.tech/backend.autotls.cert.restart-buffer`

Required: false

Default value: 6h

Backends: secretclass.adoc#backend-autotls

The amount of time the Pod using the cert gets restarted before the cert expires. Keep in mind that there can be multiple Pods - such as 80 datanodes - trying to shut down at the same time. It can take some hours until all Pods are restarted in a rolling fashion.

The format is documented in Duration format.

`secrets.stackable.tech/backend.autotls.cert.jitter-factor`

Required: false

Default value: 0.2

Backends: secretclass.adoc#backend-autotls

Up to this part of the Certificate’s lifetime may be removed for jittering.

Must be within 0.0 and 1.0.

For example, given a requested lifetime of 1 day and a jitter factor of 0.2, the certificate’s lifetime would be shortened by a random amount between 0 and 4.8 hours, leaving a certificate that will be valid for between 19.2 and 24 hours.

Jittering may be disabled by setting the jitter factor to 0.

`secrets.stackable.tech/kerberos.service.names`

Required: false

Default value: HTTP

Backends: secretclass.adoc#backend-kerberoskeytab

The service names to be prepended to the provisioned principals. The provisioned principals will have the form service/scope@realm. Multiple service names should be separated by commas (,).