* Configurable lock and request etcd timeouts.
If etcd cluster placed on slow servers - request timeouts may be much greater, then hardcoded default values.
Also, in etcd setup, like above - may be need to greater lock timeout.
* Configurable lock and request etcd timeouts.
Docs.
* Use user friendly timeout syntax.
To allow specify more readable time values.
* Adding the CLI flag placement info
* Adding the definition of 'options' and 'args'
* tweaked the wording a little bit
* Added more description in the example
* Added a link to 'Flags' in the doc for options def
* Fix typo in documentation
* Update fdb-go-install.sh for new release tags
* Exclude FoundationDB bindings from vendoring, delete vendored copy
FoundationDB bindings are tightly coupled to the server version and
client library version used in a specific deployment. Bindings need
to be installed using the fdb-go-install.sh script, as documented in
the foundationdb backend documentation.
* Add TLS support to FoundationDB backend
TLS support appeared in FoundationDB 5.2.4, raising the minimum API version
for TLS-aware FoundationDB code to 520.
* Update documentation for FoundationDB TLS support
This changes the behavior of the GCPCKMS auto-unsealer setup to attempt
encryption instead of a key lookup. Key lookups are a different API
method not covered by roles/cloudkms.cryptoKeyEncrypterDecrypter. This
means users must grant an extended scope to their service account
(granting the ability to read key data) which only seems to be used to
validate the existence of the key.
Worse, the only roles that include this permission are overly verbose
(e.g. roles/viewer which gives readonly access to everything in the
project and roles/cloudkms.admin which gives full control over all key
operations). This leaves the user stuck between choosing to create a
custom IAM role (which isn't fun) or grant overly broad permissions.
By changing to an encrypt call, we get better verification of the unseal
permissions and users can reduce scope to a single role.
* Add KMS Rekey example
I've had customers looking for AWS KMS rekeying examples today - when using pgp keys.
This example would have clarified what they needed to do.
* Replaced KMS reference with Auto Unseal
``` bash
Rekey an Auto Unseal vault and encrypt the resulting recovery keys with PGP:
```
* Add example for AWS KMS AutoUnseal with PGP Keys
A customer could not figure how to get this working today.
This example would have helped them. We don't mention KMS anywhere in this section.
* Changed reference from AWS KMS to Auto Unseal
``` bash
Initialize Auto Unseal, but encrypt the recovery keys with pgp keys:
```
The docs hadn't been updated to reflect the ability to do cross-account
AWS IAM auth, and so it was a bit confusing as to whether that was
supported. This removes the ambiguity by explicitly mentioning AWS IAM
principals.
