What causes "core: seal configuration missing, not initialized" error

I’m just curious as to what could be the reasons for that error? - core: seal configuration missing, not initialized

Hello,

Usually this error is shown when the Vault’s storage backend is not initialized. You can initialize it with vault operator init.

Martin

1 Like

Hey Martin,

Thanks for the reply.

I’m actually using http api and all of this is happening in Kubernetes.

        log "Pod Ip is: $pod_ip"
        out="$(curl --insecure -g -s ${protocol}://${pod_ip}:8200/v1/sys/init)"
        echo "$out"

i’m getting the pod ip, and calling sys/init API and echo-ing the output.

The output says - {“errors”:[“core: barrier reports initialized but no seal configuration found”]}

I’m initializing vault later in the code and I’m expecting the output to be
{“initialized”:false}. But I don’t understand why the error?

Why not just give the output as {“initialized”:false}?

I also want to say that sometimes I get {“initialized”:false} in “$out” and sometimes {“errors”:[“core: barrier reports initialized but no seal configuration found”]} in the same “$out”

I find that really weird. What am I doing wrong?

Hello,

What does the vault status say ?

Martin

[root@jade-cw01 ~]# curl --insecure -g -s https://[2001:db8:1234::39d5]:8200/v1/sys/seal-status
{“type”:“shamir”,“initialized”:false,“sealed”:true,“t”:0,“n”:0,“progress”:0,“nonce”:"",“version”:"",“migration”:false,“recovery_seal”:false,“storage_type”:“mysql”}

[root@jade-cw01 ~]# curl --insecure -g -s --request PUT --data ‘{“secret_shares”: 1, “secret_threshold”: 1}’ https://[2001:db8:1234::39d5]:8200/v1/sys/init
{“errors”:[“core: barrier reports initialized but no seal configuration found”]}

Hello,

Is this HA setup, if yes do you try to do init on both nodes at the same time ?

Has it ever been initialized ?

What is the seal stanza do you use, Shamir, auto-unseal ?

Martin

The setup looks like this -

secretstore-cskm-0 has vault installed.
Once we confirm that vault is installed in that pod, secretstore-cskm-post-install-jobs-xxxxx will acquire the pod-ip and make calls to secretstore-cskm-0 to initialize, unseal and perform a health check on the vault. if it fails to do any of those, it will result in an error.

secretstore-cskm-0 is one pod but it has two containers running.

If call to sys/init api returns {“initialized”:true}, we won’t try to initialize it again, if it’s not we will try to initialize vault again.

I don’t believe we’re using a seal configuration. I think it’s optional, right?
bash-4.4$ cat /etc/vault/vault_config.hcl
storage “mysql” { address = “secretstore-
mariadb.hookv6.svc.cluster.local:3306” ha_enabled = “true” username =
“xxxx” password = “xxxx” database = “xxxx” } listener “tcp” { address = "
[::]:8200" tls_key_file = “/opt/vault/tls/tls.key”
tls_cert_file="/opt/vault/tls/tls.crt" } disable_mlock = true