* Make useCache explicit everywhere in lock manager
This also clears up a case where we could insert into the cache when it
wasn't active
* Address feedback
* Fix a couple of instances where we are using LIST verb
We specify it for the wrapping lookup function but for broader
compatibility with proxies and such we want to filter it to a GET. In a
couple of places we weren't doing that, so this updates those locations.
* fix cubbyhole deletion
* Fix error handling
* Move the cubbyhole tidy logic to token store and track the revocation count
* Move fetching of cubby keys before the tidy loop
* Fix context getting cancelled
* Test the cubbyhole cleanup logic
* Add progress counter for cubbyhole cleanup
* Minor polish
* Use map instead of slice for faster computation
* Add test for cubbyhole deletion
* Add a log statement for deletion
* Add SHA1 hashed tokens into the mix
* add dot-to-dash helper
* fix context menu on policy page and add test for deletion
* use dot-to-dash where we use confirm component
* fix acceptance test
The result will still pass gofmtcheck and won't trigger additional
changes if someone isn't using goimports, but it will avoid the
piecemeal imports changes we've been seeing.
* 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.
* Docker support for postgres backend testing
* Bug in handling of postgres connection url for non docker testing
* Test should fail if it cannot retrieve pg version
* internal helperfunctions pascalCasing
* 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:
```
* don't pass id when using createRecord
* add find nearest ancestor mixin
* re-throw the error if we've deleted something and encounter a 404
* use the with-nav-to-nearest-ancestor mixin
* add some comments
* add acceptance test to verify new behavior
* yield final transition in ec task
