* 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
* add performanceStandbyCount to license model
* use count to determine if perf standby is an active feature
* rename test file and add tests for new perf standby behavior
* Update ui/app/templates/components/license-info.hbs
* update display language
* 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:
```
* Strip empty strings from database revocation stmts
It's technically valid to give empty strings as statements to run on
most databases. However, in the case of revocation statements, it's not
only generally inadvisable but can lead to lack of revocations when you
expect them. This strips empty strings from the array of revocation
statements.
It also makes two other changes:
* Return statements on read as empty but valid arrays rather than nulls,
so that typing information is inferred (this is more in line with the
rest of Vault these days)
* Changes field data for TypeStringSlice and TypeCommaStringSlice such
that a client-supplied value of `""` doesn't turn into `[]string{""}`
but rather `[]string{}`.
The latter and the explicit revocation statement changes are related,
and defense in depth.
