Threshold shares/number of shares discrepancy

[echenran]

There seems to be a discrepancy with the threshold number of shares and the number of shares available in a created Vaulted instance. I know the default values for Vaulted are shares=3 and threshold=2, but my Vault server has shares=1 and threshold=1, and the Vaulted object seems to be representing both.

{ domain: null, _events: { init: [Function], unsealed: [Function], mount: [Function], unmount: [Function] }, _maxListeners: undefined, config: { _data: { vault_token: debug: false, vault_host: '127.0.0.1', vault_port: 8200, vault_ssl: false, ssl_ciphers: 'TLSv1.2', ssl_verify: true, secret_shares: 3, secret_threshold: 2 } }, api: { endpoints: { 'sys/init': [Object], 'sys/seal-status': [Object], 'sys/seal': [Object], 'sys/unseal': [Object], 'sys/mounts/:id': [Object], 'sys/mounts/:id/tune': [Object], 'sys/remount': [Object], 'sys/auth/:id': [Object], 'sys/policy/:id': [Object], 'sys/audit/:id': [Object], 'sys/audit-hash/:id': [Object], 'sys/renew/:id': [Object], 'sys/revoke/:id': [Object], 'sys/revoke-prefix/:id': [Object], 'sys/leader': [Object], 'sys/raw': [Object], 'sys/health': [Object], 'sys/key-status': [Object], 'sys/rotate': [Object], 'sys/rekey/init': [Object], 'sys/rekey/update': [Object], 'cubbyhole/:id': [Object], 'auth/token/create': [Object], 'auth/token/lookup-self': [Object], 'auth/token/lookup/:id': [Object], 'auth/token/revoke/:id': [Object], 'auth/token/revoke-self': [Object], 'auth/token/revoke-orphan/:id': [Object], 'auth/token/revoke-prefix/:id': [Object], 'auth/token/renew/:id': [Object], 'secret/:id': [Object] }, specs: { v1: [Object] } }, status: { sealed: false, t: 1, n: 1, progress: 0 },

There's more to the Vaulted object but that's the relevant part. I've bolded the parts that don't line up. This results when I don't set secret_shares and secret_threshold in my conf variable.

My question is, what exactly is shares=3 threshold=2 referring to, since it can't be the config for vault unsealing? And why aren't they overridden by the server's share/threshold numbers?

[kenjones-cisco]

If no configurations are provided when creating the Vaulted instance, then that is the config object and those are the default values. If you pass in secret_shares and secret_threshold to the init api then those are the values used but if you don't pass in values to the api directly then the defaults will be used.

The default values can be overridden using a configuration file, environment variables, or by passing values to the Vaulted constructor.

[echenran]

Right, I understand that.

My question, again, is why the Vaulted object is representing two different sets of share/threshold configurations. According to Vault's page on sealing and unsealing, the vault can be unsealed by both command line (server side) and by API (Vaulted client). Fine. That's all very good. Doesn't it stand to reason that both the server and the client should abide by the same parameters to unseal, whether that's s=3/t=2 or s=1/t=1?

Unless Vaulted was intended to follow a separate config from the server to unseal...If that's the case, please explain why Vaulted was designed that way.

[chiefy]

@echenran I don't believe that Vaulted knows about how you initialized your vault - unless you do it through Vaulted. So if you have initialized a vault externally, we do not check the seal-status and compare it to any config the user has provided.

I suppose that if you passed a configuration flag, something like : vault_pre_initialized: true we could query the API for the seal-status and use that.

Or, we could simply compare what we get back from seal-status to user provided config and throw an exception if they differ?

@kenjones-cisco thoughts?

[chiefy]

haven't heard back on this, so closing it.