* Fixed the broken link
* Fixing the broken link
* Fixes redirect to Tokens guide
The separate redirect within learn.hashicorp.com will be fixed on its own repo.
* 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:
```
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
* Adding support for Consul 1.4 ACL system
* Working tests
* Fixed logic gate
* Fixed logical gate that evaluate empty policy or empty list of policy names
* Ensure tests are run against appropiate Consul versions
* Running tests against official container with a 1.4.0-rc1 tag
* policies can never be nil (as even if it is empty will be an empty array)
* addressing feedback, refactoring tests
* removing cast
* converting old lease field to ttl, adding max ttl
* cleanup
* adding missing test
* testing wrong version
* adding support for local tokens
* addressing feedback
The original wording made it appear as if SQL statements were being executed against a MongoDB backend, which is incorrect and confusing. Fixed to better reflect what is actually occurring.
* docs(systemd): `Capabilities` had been removed
The `Capabilities=` unit file setting has been removed and is ignored for
backwards compatibility. `AmbientCapabilities=` and `CapabilityBoundingSet=`
should be used instead.
8f968c7321/NEWS (L1357)
* style: remove trailing white space
* website: remove mention of `@` in command
The command does not contain the mentioned `@` symbol and can be
confusing.
* docs: use `policy-name` instead of `my-policy`
Just making things consistent.
The seal already supported an endpoint configuration, but it wasn't
documented, so adding the docs for it. Also adding a note on required
KMS permissions.
* Added role-option max_sts_ttl to cap TTL for AWS STS credentials.
* Allow for setting max_sts_ttl to 0 after it has been set already.
* Fixed message in error response for default_sts_ttl > max_sts_ttl.
* conversion stage 1
* correct image paths
* add sidebar title to frontmatter
* docs/concepts and docs/internals
* configuration docs and multi-level nav corrections
* commands docs, index file corrections, small item nav correction
* secrets converted
* auth
* add enterprise and agent docs
* add extra dividers
* secret section, wip
* correct sidebar nav title in front matter for apu section, start working on api items
* auth and backend, a couple directory structure fixes
* remove old docs
* intro side nav converted
* reset sidebar styles, add hashi-global-styles
* basic styling for nav sidebar
* folder collapse functionality
* patch up border length on last list item
* wip restructure for content component
* taking middleman hacking to the extreme, but its working
* small css fix
* add new mega nav
* fix a small mistake from the rebase
* fix a content resolution issue with middleman
* title a couple missing docs pages
* update deps, remove temporary markup
* community page
* footer to layout, community page css adjustments
* wip downloads page
* deps updated, downloads page ready
* fix community page
* homepage progress
* add components, adjust spacing
* docs and api landing pages
* a bunch of fixes, add docs and api landing pages
* update deps, add deploy scripts
* add readme note
* update deploy command
* overview page, index title
* Update doc fields
Note this still requires the link fields to be populated -- this is solely related to copy on the description fields
* Update api_basic_categories.yml
Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages.
* Add bottom hero, adjust CSS, responsive friendly
* Add mega nav title
* homepage adjustments, asset boosts
* small fixes
* docs page styling fixes
* meganav title
* some category link corrections
* Update API categories page
updated to reflect the second level headings for api categories
* Update docs_detailed_categories.yml
Updated to represent the existing docs structure
* Update docs_detailed_categories.yml
* docs page data fix, extra operator page remove
* api data fix
* fix makefile
* update deps, add product subnav to docs and api landing pages
* Rearrange non-hands-on guides to _docs_
Since there is no place for these on learn.hashicorp, we'll put them
under _docs_.
* WIP Redirects for guides to docs
* content and component updates
* font weight hotfix, redirects
* fix guides and intro sidenavs
* fix some redirects
* small style tweaks
* Redirects to learn and internally to docs
* Remove redirect to `/vault`
* Remove `.html` from destination on redirects
* fix incorrect index redirect
* final touchups
* address feedback from michell for makefile and product downloads
1. Using the current tutorial will return a warning after creating the role "my-role:
```bash
WARNING! The following warnings were returned from Vault:
* Detected use of legacy role or policy parameter. Please upgrade to use the
new parameters.
```
To fix this we need to update the command and the query. Correct entries can be found in documentation for the [AWS Engine](https://www.vaultproject.io/docs/secrets/aws/index.html).
2. `vault revoke` to `vault lease revoke`. The command bellow is updated, but the text above it was not.
* Set allowed OIDs to any value when generaing a CA.
Also, allow utf-8 in addition to utf8 as the OID type specifier, and
allow `*` to specify any OID of a supported type.
* Update PKI docs
* Add ability to configure the NotBefore property of certificates in role api
* Update index.html.md
* converting field to time.Duration
* setting default back to 30s
* renaming the parameter not_before_duration to differentiate between the NotBefore datetime on the cert
* Update description
* Allow specifying role-default TTLs in AWS secret engine
* Add an acceptance test
* Add docs for AWS secret role-default TTLs
* Rename default_ttl to default_sts_ttl
* Return default_ttl as int64 instead of time.Duration
* Fix broken tests
The merge of #5383 broke the tests due to some changes in the test style
that didn't actually cause a git merge conflict. This updates the tests
to the new style.
* The added method customTLSDial() creates a tls connection to the zookeeper backend when 'tls_enabled' is set to true in config
* Update to the document for TLS configuration that is required to enable TLS connection to Zookeeper backend
* Minor formatting update
* Minor update to the description for example config
* As per review comments from @kenbreeman, additional property description indicating support for multiple Root CAs in a single file has been added
* minor formatting
In addition to the specific permissions that are already mentioned, the project also needs the `iam.googleapis.com` API enabled, otherwise authenticating will fail with an error similar to:
```
Error authenticating: Error making API request.
URL: PUT https://localhost:8200/v1/auth/gcp/login
Code: 400. Errors:
* could not find service account key or Google Oauth cert with given 'kid' id
```
Specifying the `allowed_organiztaional_units` parameter to a cert auth
backend role will require client certificates to contain at least one of
a list of one or more "organizational units" (OU).
Example use cases:
Certificates are issued to entities in an organization arrangement by
organizational unit (OU). The OU may be a department, team, or any other logical
grouping of resources with similar roles. The entities within the OU
should be granted the same policies.
```
$ vault write auth/cert/certs/ou-engineering \
certificate=@ca.pem \
policies=engineering \
allowed_organiztaional_units=engineering
$ vault write auth/cert/certs/ou-engineering \
certificate=@ca.pem \
policies=engineering \
allowed_organiztaional_units=engineering,support
```
* auth/aws: Make identity alias configurable
This is inspired by #4178, though not quite exactly what is requested
there. Rather than just use RoleSessionName as the Identity alias, the
full ARN is uses as the Alias. This mitigates against concerns that an
AWS role with an insufficiently secured trust policy could allow an
attacker to generate arbitrary RoleSessionNames in AssumeRole calls to
impersonate anybody in the Identity store that had an alias set up.
By using the full ARN, the owner of the identity store has to explicitly
trust specific AWS roles in specific AWS accounts to generate an
appropriate RoleSessionName to map back to an identity.
Fixes#4178
* Respond to PR feedback
* Remove CreateOperation
Response to PR feedback
* Add AWS Secret Engine Root Credential Rotation
This allows the AWS Secret Engine to rotate its credentials used to
access AWS. This will only work when the AWS Secret Engine has been
provided explicit IAM credentials via the config/root endpoint, and
further, when the IAM credentials provided are the only access key on
the IAM user associated wtih the access key (because AWS allows a
maximum of 2 access keys per user).
Fixes#4385
* Add test for AWS root credential rotation
Also fix a typo in the root credential rotation code
* Add docs for AWS root rotation
* Add locks around reading and writing config/root
And wire the backend up in a bunch of places so the config can get the
lock
* Respond to PR feedback
* Fix casing in error messages
* Fix merge errors
* Fix locking bugs
* Add test file for testing path_restore in Transit backend. Fails because 'force' is not implemented yet
* initial implementation of 'force', to force restore of existing transit key atomically
