"[WARN] core: stored unseal key(s) supported but none found"

[marcuschaney]

Hello All,

I'm using a pre-existing KMS Key ID to perform the Vault Auto Unseal operation, but I'm having no luck. I've ensured the EC2 instance has encrypt, decrypt and list keys access, and added the required configs to the vault config file. See below:

seal "awskms" { kms_key_id = "randomness for my KMS key" region = "us-gov-west-1" }

After restarting vault and checking the status, it's still showing "sealed". Any insight would be greatly appreciated! I'm a noob!

V/r Marcus

[chrishoffman]

What version of vault are you using? Autoseal is only available in 1.0+. If you are migrating from a Shamir seal, you will need to follow the migration steps https://www.vaultproject.io/docs/concepts/seal.html#seal-migration.

[arnarg]

I'm trying to do the same. config.json includes:

"seal": {
  "awskms": {
    "access_key": "<redacted>",
    "kms_key_id": "<redacted>",
    "region": "us-east-1",
    "secret_key": "<redacted>"
  }
}

I'm tried it with the vault image on dockerhub with tag 1.0.0, 1.0.1 and 1.0.2, all of them log out:

2019-01-29T13:56:46.291Z [INFO]  core: stored unseal keys supported, attempting fetch
2019-01-29T13:56:46.291Z [WARN]  core: stored unseal key(s) supported but none found

The IAM user with the credentials in the config has this inline policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        }
    ]
}

But I also tried with simply kms:*.

I'm following this guide (except using helm chart to deploy vault on kubernetes).

/ # vault status
Key                      Value
---                      -----
Recovery Seal Type       awskms
Initialized              false
Sealed                   true
Total Recovery Shares    0
Threshold                0
Unseal Progress          0/0
Unseal Nonce             n/a
Version                  n/a
HA Enabled               false

Doesn't seem to respect key-shares or key-threshold:

/ # vault operator init -key-shares=1 -key-threshold=1
Recovery Key 1: GUY...B4x
Recovery Key 2: +Bb...4C3
Recovery Key 3: AnI...7RL
Recovery Key 4: Sfg...hAq
Recovery Key 5: i5X...C4D

Initial Root Token: s.M3s...11N

Success! Vault is initialized

Recovery key initialized with 5 key shares and a key threshold of 3. Please
securely distribute the key shares printed above.

And changed to shamir:

/ # vault status
Key                      Value
---                      -----
Recovery Seal Type       shamir
Initialized              true
Sealed                   false
Total Recovery Shares    5
Threshold                3
Version                  1.0.2
Cluster Name             vault-cluster-2927e5bc
Cluster ID               c9797d6f-694f-6a74-4779-76bc24ddb83d
HA Enabled               false

[jefferai]

@arnarg You'll see that message if you haven't initialized Vault yet. When using auto seal you get recovery key shares; if you want to adjust them you need to use -recovery-key-shares and -recovery-key-threshold.

[arnarg]

@jefferai Thanks! It's working now. Also, not knowing how it really works, I didn't have a persistent storage under it.

[briankassouf]

Glad this was figured out!

[adv4000]

I had same messages after deployment via Helm Chart and Auto Unseal with EKS, Fixed by login to my one of the vault pods and execute vault operator init Vault require initialization, after deployment execute:

kubectl exec -it app-vault-0 "/bin/sh" -n app-vault
vault status
vault operator init
vault status

Before vault operator init:

/ $ vault status
Key                      Value
---                      -----
Recovery Seal Type       awskms
Initialized              false
Sealed                   true
Total Recovery Shares    0
Threshold                0
Unseal Progress          0/0
Unseal Nonce             n/a
Version                  1.7.3
Storage Type             dynamodb
HA Enabled               true

After vault operator init

/ $ vault status
Key                      Value
---                      -----
Recovery Seal Type       shamir
Initialized              true
Sealed                   false
Total Recovery Shares    5
Threshold                3
Version                  1.7.3
Storage Type             dynamodb
Cluster Name             vault-cluster-xxxxxx
Cluster ID               xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx
HA Enabled               true
HA Cluster               https://app-vault-2.app-vault-internal:8201
HA Mode                  active
Active Since             2021-07-13

[binacloud]

I'm using ECS and I keep getting this even though the API says the Vault is initialized.

[WARN] failed to unseal core: error="stored unseal keys are supported, but none were found"
[INFO] core: stored unseal keys supported, attempting fetch
[WARN] failed to unseal core: error="stored unseal keys are supported, but none were found"
[INFO] core: stored unseal keys supported, attempting fetch
[WARN] failed to unseal core: error="stored unseal keys are supported, but none were found"
[INFO] core: stored unseal keys supported, attempting fetch
[WARN] failed to unseal core: error="stored unseal keys are supported, but none were found"

Environment variables declared in container_definitions : VAULT_ADDR=https://0.0.0.0:8201/ VAULT_API_ADDR=https://127.0.0.1:8201 VAULT_SEAL_TYPE=awskms VAULT_AWSKMS_SEAL_KEY_ID=arn:aws:kms:::key/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee VAULT_UI=true VAULT_LOCAL_CONFIG={storage: {dynamodb: {ha_enabled: true, region: ${var.region}, table: ${aws_dynamodb_table.vault_dynamo.name} }}, listener: {tcp: { address: 0.0.0.0:8201, tls_disable: false, tls_cert_file: /mnt/efs/tls.crt, tls_key_file: /mnt/efs/tls.key } } }

Why is this happening?? This seems like an issue with the Vault application itself because all the AWS resources are configured correctly. If they're not, we should receive some more specific errors right?? not this vague WARN that is clearly an ERROR because it kills the container after some time.

[vini-gorillas]

I had same messages after deployment via Helm Chart and Auto Unseal with EKS, Fixed by login to my one of the vault pods and execute vault operator init Vault require initialization, after deployment execute:

kubectl exec -it app-vault-0 "/bin/sh" -n app-vault
vault status
vault operator init
vault status

Before vault operator init:

/ $ vault status
Key                      Value
---                      -----
Recovery Seal Type       awskms
Initialized              false
Sealed                   true
Total Recovery Shares    0
Threshold                0
Unseal Progress          0/0
Unseal Nonce             n/a
Version                  1.7.3
Storage Type             dynamodb
HA Enabled               true

After vault operator init

/ $ vault status
Key                      Value
---                      -----
Recovery Seal Type       shamir
Initialized              true
Sealed                   false
Total Recovery Shares    5
Threshold                3
Version                  1.7.3
Storage Type             dynamodb
Cluster Name             vault-cluster-xxxxxx
Cluster ID               xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx
HA Enabled               true
HA Cluster               https://app-vault-2.app-vault-internal:8201
HA Mode                  active
Active Since             2021-07-13

If the Recovery seal type is changed from gcpkms to shamir, how woudl the gypkms come into use when the vault has to be unsealed in real? Thamks

[kdubb]

@vini-gorillas A little late to the party but I just dealt with this and apparently, after automatically unsealing (via awskms in our case), vault status shows shamir for Recovery seal type. So this seems to be the type shown for unsealed instances.