* 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:
```
With vault-1.0.0 and vault-0.11.4 a different path is needed to list the jwt registered roles:
```
$ vault list auth/jwt/roles
No value found at auth/jwt/roles/
$ vault list auth/jwt/role
Keys
----
myrole
```
I hope this helps!
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.
Documented changes from https://github.com/hashicorp/vault-plugin-auth-gcp/pull/55
* Deprecating `project_id` for `bound_projects` and making it optional
* Deprecating `google_certs_endpoint` (unused)
* Adding group aliases
Also, some general reformatting
When configuring DynamoDB, the read and write capacities configured only
have any effect if the table does not exist. As per the comment in the
code [1], the configuration of an existing table is never modified. This
was not previously reflected in the documentation - this commit
rectifies that.
[1]: https://github.com/hashicorp/vault/blob/master/physical/dynamodb/dynamodb.go#L743-L745
* Document /sys/health?perfstandbyok
Discovered that in Vault Enterprise 0.11.5, `/sys/health?standbyok` returns a 473 status for performance standby nodes, compared to a 200 for standard standby nodes.
Turns out there was an additional `perfstandbyok` option added, here:
e5aaf80764
* Update health.html.md
Slight tweak to wording for perfstandbyok
* Add support for custom JWT path in Agent: kubernetes auth
- add support for "token_path" configuration
- add a reader for mocking in tests
* add documentation for token_path
Vishal Nayak