luxolus
/
open-vault
2
0
Fork 0
Code Issues 1 Pull Requests Releases Activity

docs: provide clarifications for github auth method and ssh secrets engine (#12495) 

* Clarify that any org GitHub user token can be used

* Clarify ssh secrets allowed_extensions behaviors
This commit is contained in:
mickael-hc 2021-09-08 11:55:35 -04:00 committed by GitHub
parent 0d04a9892a
commit d2310302a1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 11 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
website/content/docs/auth/github.mdx
View File

@ -13,7 +13,8 @@ operators or developers using Vault directly via the CLI.
~> **IMPORTANT NOTE:** Vault does not support an OAuth workflow to generate ~> **IMPORTANT NOTE:** Vault does not support an OAuth workflow to generate
GitHub tokens, so does not act as a GitHub application. As a result, this method GitHub tokens, so does not act as a GitHub application. As a result, this method
uses personal access tokens. An important consequence is that any valid GitHub uses personal access tokens. An important consequence is that any valid GitHub
access token with the `read:org` scope can be used for authentication. If such a access token with the `read:org` scope for any user belonging to the Vault-configured
organization can be used for authentication. If such a
token is stolen from a third party service, and the attacker is able to make token is stolen from a third party service, and the attacker is able to make
network calls to Vault, they will be able to log in as the user that generated network calls to Vault, they will be able to log in as the user that generated
the access token. When using this method it is a good idea to ensure that access the access token. When using this method it is a good idea to ensure that access

10
website/content/docs/secrets/ssh/signed-ssh-certificates.mdx
View File

@ -99,9 +99,17 @@ team, or configuration management tooling.
1. Create a named Vault role for signing client keys. 1. Create a named Vault role for signing client keys.
~> **IMPORTANT NOTE:** If `"allowed_extensions"` is either empty or not specified in the role,
[Vault will assume permissive defaults](/api/secret/ssh#allowed_extensions): any user assigned
to the role would be able to specify any arbitrary extension values as part of the certificate request to the Vault server.
This may have significant impact on third-party systems that rely on an `extensions` field for security-critical information.
In those cases, consider using a template to specify default extensions, and explicitly setting
`"allowed_extensions"` to an arbitrary, non-empty string if the field is empty or not set.
Because of the way some SSH certificate features are implemented, options Because of the way some SSH certificate features are implemented, options
are passed as a map. The following example adds the `permit-pty` extension are passed as a map. The following example adds the `permit-pty` extension
to the certificate. to the certificate, and allows the user to specify their own values for `permit-pty` and `permit-port-forwarding`
when requesting the certificate.
```text ```text
$ vault write ssh-client-signer/roles/my-role -<<"EOH" $ vault write ssh-client-signer/roles/my-role -<<"EOH"