Can't init 1.12.0 with awskms

[davidcorrigan714]

Describe the bug When running vault operator init on a new install of 1.12.0 errors with "* parameters secret_shares,secret_threshold not applicable to seal type awskms". I tried with the web UI too and got something similar.

Environment:

• Vault Server Version (retrieve with vault status): 1.12.0
• Vault CLI Version (retrieve with vault version): Vault v1.5.9 (cgo)
• Server Operating System/Architecture: Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-1021-aws x86_64)

Vault server configuration file(s):

ui = true
disable_mlock = true

storage "dynamodb" {
  ha_enabled = "true"
  region     = "us-east-1"
  table      = "VaultDB"
}

cluster_addr = "https://...:8201"
api_addr = "https://...:8200"
listener "tcp" {
  address            = "0.0.0.0:8200"
  tls_disable        = false
  tls_cert_file      = "/opt/vault/tls/certificates/....crt"
  tls_key_file       = "/opt/vault/tls/certificates/....key"
  tls_disable_client_certs = true
}

plugin_directory = "/opt/vault/plugins"

seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "arn:aws:kms:us-east-1..."
}

[davidcorrigan714]

Went to debug this some more and now it's working. Been doing a bunch of work on my bootstrap script for deploying it all to AWS, unfortunately nothing comes to mind that may have affected this.

[omarelsheekh]

@davidcorrigan714 Hi David, Can you please mention how could you fix it? I got this same error, but I Couldn't solve it

[davidcorrigan714]

@omarelsheekh I've been deploying it all from Terraform from nothing and haven't hit it since that first time. Around the same time I first hit that I switched from doing it in the UI manually to doing it at the end of the deployment through the CLI so I'm wondering if it only happens if you try it through the UI first. I can try again tomorrow through the UI and see if it hits it again.

[fancybear-dev]

I have the same problem with Vault 1.12.0. Our situation is a bit different though, we use GCPKMS. The error is the same. Via the UI you are unable to init Vault, also via the /sys/init endpoint - both same error as you have. Using the Vault CLI (remote, not required locally) with the same version (if not same version - it will also produce the same error), you can initialize Vault with the vault operator init command.

Example of what we use purely for init on a local machine to remote cluster (change host and version accordingly); docker run --rm --cap-add=IPC_LOCK --name=dev-vault vault:1.12.0 vault operator init -address="http://1.1.1.1:8200"

[joliver]

Just saw this as well. In our case, we're using the Vault raft storage engine and some of the Vault instances didn't come online properly so it couldn't form a quorum. The error we received was parameters secret_shares,secret_threshold not applicable to seal type transit

We fixed the automation script so the other nodes come online properly and the error disappeared.

[aminubakori]

Battled with this over the past 24 Hours.

The fix is to remove the parameters secret_shares and secret_threshold from your JSON payload. Once removed, send a PUT request with the payload below to ${VAULT_SERVICE_URL}/v1/sys/init.

{ "recovery_shares": 1, "recovery_threshold": 1, "stored_share": 1 }

This should return the valid response with root_token, recovery_keys and recovery_keys_base64.

[marvingfx]

Swapping secret_shares and secret_threshold for recovery_shares and recovery_threshold indeed does the trick. After actually really reading the docs, we found the solution here and here.

[stevendpclark]

The answers from @aminubakori and @marvingfx are correct. Within Vault 1.12 the parameter validation for the init call was tightened up resulting in requiring using a vault 1.12 client (for calling vault operator init) or sending the appropriate parameters to the API call.