Chart Is Not Compliant with the K8s Standard Hostpath Provisioner

[Xtigyro]

dataStorage:
    enabled: true

Causes:

/ # vault operator init
Error initializing: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/sys/init
Code: 400. Errors:

* failed to initialize barrier: failed to persist keyring: mkdir /vault/data/core: permission denied

The chart expects a non-default Hostpath provisioner to be used - for ex., AWS EBS.

[jasonodonnell]

You can specify the name of the storage class:

  dataStorage:
    enabled: true
    # Size of the PVC created
    size: 10Gi
    # Name of the storage class to use.  If null it will use the
    # configured default Storage Class.
    storageClass: null
    # Access Mode of the storage device being used for the PVC
    accessMode: ReadWriteOnce

Non-storage class (hostpath, nfs, etc) options aren't supported at this time.

[Xtigyro]

You can specify the name of the storage class:

  dataStorage:
    enabled: true
    # Size of the PVC created
    size: 10Gi
    # Name of the storage class to use.  If null it will use the
    # configured default Storage Class.
    storageClass: null
    # Access Mode of the storage device being used for the PVC
    accessMode: ReadWriteOnce

Non-storage class (hostpath, nfs, etc) options aren't supported at this time.

@jasonodonnell Hey Jason! Yes - you can specify the name of the StorageClass. And if you don't - the Standard (default) one is used.

So if a local Persistent Volume of type hostPath is used - the chart expects that the mounted directory is writeable by non-root users. That is not the default behaviour when using a default deployment of Kubernetes which does not have any custom Storage Classes and their respective custom Storage Provisioners defined - for ex., AWS EBS and AWS GP2 which mounts the PV as globally writeable.

[f0def]

For anyone who met same issue as me...

I'm using standalone installation and my volume looks like:

kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv-vault
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/pv-vault"

ssh to node-worker and execute (this is workaround):

$ cd /mnt
$ sudo chmod -R 757 pv-vault

after that I can run this command without error failed to persist keyring: mkdir /vault/data/core: permission denied:

$ kubectl exec -ti vault-0 -- vault operator init

[lohazo]

I have same issue. I endup change the mounthPath of dataStorage and it work.

  dataStorage:
    enabled: true
    # Size of the PVC created
    size: 10Gi
    # Location where the PVC will be mounted.
    mountPath: "/somgthing/vault/data"

[philthynz]

If anyone is interested, I have been able to use Vault with an existing PV. In terraform. /mnt/data/vault is my block storage. A little messy with the Terraform values not using object references, but it works.

Create namespace

resource "kubernetes_namespace" "nextcloud" {
  metadata {
    name = "vault"
  }
}

Create a storage class

resource "kubernetes_storage_class" "local-storage" {
  metadata {
    name = "local-storage"
  }
  storage_provisioner = "kubernetes.io/no-provisioner"
  volume_binding_mode = "WaitForFirstConsumer"
}

Create a PV

Uses the same default values the Helm chart's dataStorage will create

resource "kubernetes_persistent_volume" "vault" {
  metadata {
    name = "data-vault-0"
    labels = {
      type = "local"
    }
  }
  spec {
    capacity = {
      storage = "5Gi"
    }
    access_modes = ["ReadWriteOnce"]
    persistent_volume_source {
      local {
        path = "/mnt/data/vault"
      }
    }
    storage_class_name = "local-storage"

    node_affinity {
      required {
        node_selector_term {
          match_expressions {
            key = "kubernetes.io/hostname"
            operator = "In"
            values   = ["k3s"] # This is the kubernetes node hostname
          }
        }
      }
    }
  }
}

Create the PV claim

resource "kubernetes_persistent_volume_claim" "vault" {
  metadata {
    name = "${kubernetes_persistent_volume.vault.metadata.0.name}"
    namespace = "vault"
    labels = {
      "app.kubernetes.io/instance" = "vault"
      "app.kubernetes.io/name" = "vault"
    }
  }
  spec {
    access_modes = ["ReadWriteOnce"]
    resources {
      requests = {
        storage = "5Gi"
      }
    }
    volume_name = "${kubernetes_persistent_volume.vault.metadata.0.name}"
    storage_class_name = "local-storage"
  }
}

In the Helm chart values

  dataStorage:
    enabled: true
    size: 5Gi
    mountPath: "/vault/data"
    storageClass: "local-storage"
    accessMode: ReadWriteOnce
    annotations: {}

Deploy Vault via Helm

resource "helm_release" "vault" {
  depends_on       = [kubernetes_persistent_volume_claim.vault]
  name             = "vault"
  namespace        = "vault"
  create_namespace = true
  repository       = "https://helm.releases.hashicorp.com"
  chart            = "vault"
  cleanup_on_fail  = true
  lint             = true

  values = [
    "${file("${path.module}/vault.values.yml")}"
  ]
}

[yurifrl]

I was having the failed to persist keyring: mkdir /vault/data/core: permission denied error. I tried the init container approach but I was getting errors because the vault user couldn't change the permission of the folder, and I didn't want to change the service account of the container, and in general, I didn't want to change the chart, so I did this

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-vault-0
  namespace: kube-system
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: longhorn
  volumeMode: Filesystem
---
apiVersion: v1
kind: Pod
metadata:
  name: data-vault-setup
spec:
  containers:
    - name: file-permissions
      image: busybox:1.28
      command: ["chown", "-R", " ", "/vault/data"]
      securityContext:
        runAsUser: 0
        privileged: true
      volumeMounts:
        - name: data
          mountPath: /vault/data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: data-vault-0