The example request for "Generate Intermediate" was type "internal", but the example response contained the private key, which "internal" doesn't do. This patch fixes the example request to be type "exported" to match the example response.
This typo is related to https://github.com/hashicorp/vault/issues/7603 . The typo was causing issues with getting this working correctly when following the guide. I imagine any other newbie to this plugin will have the same struggle. I had to delve into the source code to figure it out
* document the require_request_header option in Agent
* document the require_request_header option in Agent
* document the require_request_header option in Agent
* document the require_request_header option in Agent
* minor tweaks to docs
Currently whenever we start a new C* session in the database plugin, we
run `LIST ALL` to determine whether we are a superuser, or otherwise
have permissions on roles. This is a fairly sensible way of checking
this, except it can be really slow when you have a lot of roles (C*
isn't so good at listing things). It's also really intensive to C* and
leads to a lot of data transfer. We've seen timeout issues when doing
this query, and can of course raise the timeout, but we'd probably
prefer to be able to switch it off.
* secrets/aws: Support permissions boundaries on iam_user creds
This allows configuring Vault to attach a permissions boundary policy to
IAM users that it creates, configured on a per-Vault-role basis.
* Fix indentation of policy in docs
Use spaces instead of tabs
Fixed malformed json example (removed extra comma). Here's the payload parse error I was running into with the example.
```
{
"rotation_period":"12h",
"verification_ttl":43200,
}
```
Vault does not like this JSON.
```
curl -s \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload-2.json \
http://127.0.0.1:8200/v1/identity/oidc/key/named-key-001 | jq
{
"errors": [
"failed to parse JSON input: invalid character '}' looking for beginning of object key string"
]
}
```
Vaulted is no longer maintained according to the readme.
https://github.com/chiefy/vaulted#vaulted
"No Longer Being Maintained Use node-vault for future support of Vault features!"
* secret/aws: Pass policy ARNs to AssumedRole and FederationToken roles
AWS now allows you to pass policy ARNs as well as, and in addition to,
policy documents for AssumeRole and GetFederationToken (see
https://aws.amazon.com/about-aws/whats-new/2019/05/session-permissions/).
Vault already collects policy ARNs for iam_user credential types; now it
will allow policy ARNs for assumed_role and federation_token credential
types and plumb them through to the appropriate AWS calls.
This brings along a minor breaking change. Vault roles of the
federation_token credential type are now required to have either a
policy_document or a policy_arns specified. This was implicit
previously; a missing policy_document would result in a validation error
from the AWS SDK when retrieving credentials. However, it would still
allow creating a role that didn't have a policy_document specified and
then later specifying it, after which retrieving the AWS credentials
would work. Similar workflows in which the Vault role didn't have a
policy_document specified for some period of time, such as deleting the
policy_document and then later adding it back, would also have worked
previously but will now be broken.
The reason for this breaking change is because a credential_type of
federation_token without either a policy_document or policy_arns
specified will return credentials that have equivalent permissions to
the credentials the Vault server itself is using. This is quite
dangerous (e.g., it could allow Vault clients access to retrieve
credentials that could modify Vault's underlying storage) and so should
be discouraged. This scenario is still possible when passing in an
appropriate policy_document or policy_arns parameter, but clients should
be explicitly aware of what they are doing and opt in to it by passing
in the appropriate role parameters.
* Error out on dangerous federation token retrieval
The AWS secrets role code now disallows creation of a dangerous role
configuration; however, pre-existing roles could have existed that would
trigger this now-dangerous code path, so also adding a check for this
configuration at credential retrieval time.
* Run makefmt
* Fix tests
* Fix comments/docs
