Skip to main content

Custom Resource

What is the SLV CRD?​

An SLV vault isn’t limited to a local file .Its manifest is already structured to work as a Kubernetes object. You can run kubectl apply -f vault.slv.yaml, and Kubernetes will treat it like any other resource. Before you do that, though, the cluster must understand what an SLV resource is. That’s the job of the CustomResourceDefinition (CRD). Apply the CRD once and the API server adds a new kind called SLV. After the CRD is in place, you’re free to create, update, or delete SLV objects exactly as you would Deployments or ConfigMaps—using the same YAML tooling and RBAC rules you already rely on.

Structure of the Custom Resource​

You will typically not need to manually create an SLV resource; the SLV binary handles this automatically. However, for understanding purposes, a typical SLV custom resource looks like this:

# This file is managed by SLV. DO NOT EDIT THIS FILE MANUALLY.
apiVersion: slv.sh/v1
kind: SLV
metadata:
  name: vault
  namespace: slv
spec:
  slvConfig:
    id: SLV_VID_...
    publicKey: SLV_VPK_...
    wrappedKeys:
      - SLV_EWK_...
  slvData:
    key1: SLV_VSS_...
    key2: SLV_VSS_...

The structure mirrors the local file-based vault, ensuring consistency between local and Kubernetes deployments.

Starting with version 0.9.0, SLV maintains a unified vault structure across all environments. Older vault formats remain compatible and are automatically migrated upon updates.

Reconciling Secrets from the Vault​

Since the vault stores encrypted data, applications cannot consume it directly. To make secrets consumable, the SLV resources must be reconciled into Kubernetes Secrets.

Note: Before reconciliation, ensure that the environment secret key or binding is loaded into the cluster. More details on loading secrets will be provided later.

Modes of Reconciliation​

Note: reconcilation happens only within a namespace and is one-to-one. i.e, If you create an SLV object in a namespace, the corresponding secret would be created in the same namespace with the same name as the object.

There are three supported ways to reconcile SLV vault objects into Kubernetes Secrets:

  • Runs continuously as a Kubernetes Deployment.
  • Watches SLV custom resources and immediately reconciles any changes.
  • Ideal for environments requiring real-time updates and automation.

2. Job (One-Off Reconciliation)​

  • Reconciles SLV objects once and exits.
  • Best suited for clusters where running a continuous operator is impractical.
  • Good for manual, controlled reconciliation workflows.

3. CronJob (Scheduled Reconciliation)​

  • Periodically reconciles SLV objects on a defined schedule.
  • Useful when delayed synchronization is acceptable, and immediate consistency is not critical.