backport of commit 1d61aeb8aebc96eecbb6a35e10bd914b4d0f41f4 (#23250)
Co-authored-by: Sergey Kutovoy <kutovoy.s@gmail.com>
This commit is contained in:
hc-github-team-secure-vault-core
GitHub
parent
86404bf211
commit
c29b24b07d
|
|
@ -0,0 +1,3 @@
|
|||
```release-note:bug
|
||||
docs: fix wrong api path for ldap secrets cli-commands
|
||||
```
|
||||
|
|
@ -34,7 +34,7 @@ The secrets engine has three primary features:
|
|||
to generate passwords:
|
||||
|
||||
```sh
|
||||
$ vault write auth/ldap/config \
|
||||
$ vault write ldap/config \
|
||||
binddn=$USERNAME \
|
||||
bindpass=$PASSWORD \
|
||||
url=ldaps://138.91.247.105
|
||||
|
|
@ -45,7 +45,7 @@ The secrets engine has three primary features:
|
|||
3. Rotate the root password so only Vault knows the credentials:
|
||||
|
||||
```sh
|
||||
$ vault write -f auth/ldap/rotate-root
|
||||
$ vault write -f ldap/rotate-root
|
||||
```
|
||||
|
||||
Note: it's not possible to retrieve the generated password once rotated by Vault.
|
||||
|
|
@ -80,7 +80,7 @@ Generated passwords must be 8 characters or less to support RACF. The length of
|
|||
password can be configured using a [password policy](/vault/docs/concepts/password-policies):
|
||||
|
||||
```bash
|
||||
$ vault write auth/ldap/config \
|
||||
$ vault write ldap/config \
|
||||
binddn=$USERNAME \
|
||||
bindpass=$PASSWORD \
|
||||
url=ldaps://138.91.247.105 \
|
||||
|
|
@ -94,7 +94,7 @@ For managing Active Directory instances, the secret engine must be configured to
|
|||
schema `ad`.
|
||||
|
||||
```bash
|
||||
$ vault write auth/ldap/config \
|
||||
$ vault write ldap/config \
|
||||
binddn=$USERNAME \
|
||||
bindpass=$PASSWORD \
|
||||
url=ldaps://138.91.247.105 \
|
||||
|
|
@ -109,7 +109,7 @@ $ vault write auth/ldap/config \
|
|||
Password rotation settings will be managed by this role.
|
||||
|
||||
```sh
|
||||
$ vault write auth/ldap/static-role/hashicorp \
|
||||
$ vault write ldap/static-role/hashicorp \
|
||||
dn='uid=hashicorp,ou=users,dc=hashicorp,dc=com' \
|
||||
username='hashicorp' \
|
||||
rotation_period="24h"
|
||||
|
|
@ -118,7 +118,7 @@ $ vault write auth/ldap/config \
|
|||
2. Request credentials for the "hashicorp" role:
|
||||
|
||||
```sh
|
||||
$ vault read auth/ldap/static-cred/hashicorp
|
||||
$ vault read ldap/static-cred/hashicorp
|
||||
```
|
||||
|
||||
### Password rotation
|
||||
|
|
@ -155,7 +155,7 @@ rotated prior to deleting the role or revoking access to the static role.
|
|||
Dynamic credentials can be configured by calling the `/role/:role_name` endpoint:
|
||||
|
||||
```bash
|
||||
$ vault write auth/ldap/role/dynamic-role \
|
||||
$ vault write ldap/role/dynamic-role \
|
||||
creation_ldif=@/path/to/creation.ldif \
|
||||
deletion_ldif=@/path/to/deletion.ldif \
|
||||
rollback_ldif=@/path/to/rollback.ldif \
|
||||
|
|
@ -169,7 +169,7 @@ executed if the creation fails for any reason. This ensures any entities are rem
|
|||
To generate credentials:
|
||||
|
||||
```bash
|
||||
$ vault read auth/ldap/creds/dynamic-role
|
||||
$ vault read ldap/creds/dynamic-role
|
||||
Key Value
|
||||
--- -----
|
||||
lease_id ldap/creds/dynamic-role/HFgd6uKaDomVMvJpYbn9q4q5
|
||||
|
|
@ -283,7 +283,7 @@ to an AD server.
|
|||
$ vault secrets enable ldap
|
||||
Success! Enabled the ad secrets engine at: ldap/
|
||||
|
||||
$ vault write auth/ldap/config \
|
||||
$ vault write ldap/config \
|
||||
binddn=$USERNAME \
|
||||
bindpass=$PASSWORD \
|
||||
url=ldaps://138.91.247.105 \
|
||||
|
|
@ -293,7 +293,7 @@ $ vault write auth/ldap/config \
|
|||
Our next step is to designate a set of service accounts for check-out.
|
||||
|
||||
```shell-session
|
||||
$ vault write auth/ldap/library/accounting-team \
|
||||
$ vault write ldap/library/accounting-team \
|
||||
service_account_names=fizz@example.com,buzz@example.com \
|
||||
ttl=10h \
|
||||
max_ttl=20h \
|
||||
|
|
@ -312,7 +312,7 @@ When a library of service accounts has been created, view their status at any ti
|
|||
available or checked out.
|
||||
|
||||
```shell-session
|
||||
$ vault read auth/ldap/library/accounting-team/status
|
||||
$ vault read ldap/library/accounting-team/status
|
||||
Key Value
|
||||
--- -----
|
||||
buzz@example.com map[available:true]
|
||||
|
|
@ -322,7 +322,7 @@ fizz@example.com map[available:true]
|
|||
To check out any service account that's available, simply execute:
|
||||
|
||||
```shell-session
|
||||
$ vault write -f auth/ldap/library/accounting-team/check-out
|
||||
$ vault write -f ldap/library/accounting-team/check-out
|
||||
Key Value
|
||||
--- -----
|
||||
lease_id ldap/library/accounting-team/check-out/EpuS8cX7uEsDzOwW9kkKOyGW
|
||||
|
|
@ -336,7 +336,7 @@ If the default `ttl` for the check-out is higher than needed, set the check-out
|
|||
for a shorter time by using:
|
||||
|
||||
```shell-session
|
||||
$ vault write auth/ldap/library/accounting-team/check-out ttl=30m
|
||||
$ vault write ldap/library/accounting-team/check-out ttl=30m
|
||||
Key Value
|
||||
--- -----
|
||||
lease_id ldap/library/accounting-team/check-out/gMonJ2jB6kYs6d3Vw37WFDCY
|
||||
|
|
@ -353,7 +353,7 @@ check it back in."
|
|||
If no service accounts are available for check-out, Vault will return a 400 Bad Request.
|
||||
|
||||
```shell-session
|
||||
$ vault write -f auth/ldap/library/accounting-team/check-out
|
||||
$ vault write -f ldap/library/accounting-team/check-out
|
||||
Error writing data to ldap/library/accounting-team/check-out: Error making API request.
|
||||
|
||||
URL: POST http://localhost:8200/v1/ldap/library/accounting-team/check-out
|
||||
|
|
@ -380,7 +380,7 @@ ends.
|
|||
To check a service account back in for others to use, call:
|
||||
|
||||
```shell-session
|
||||
$ vault write -f auth/ldap/library/accounting-team/check-in
|
||||
$ vault write -f ldap/library/accounting-team/check-in
|
||||
Key Value
|
||||
--- -----
|
||||
check_ins [fizz@example.com]
|
||||
|
|
@ -390,7 +390,7 @@ Most of the time this will just work, but if multiple service accounts are check
|
|||
caller, Vault will need to know which one(s) to check in.
|
||||
|
||||
```shell-session
|
||||
$ vault write auth/ldap/library/accounting-team/check-in service_account_names=fizz@example.com
|
||||
$ vault write ldap/library/accounting-team/check-in service_account_names=fizz@example.com
|
||||
Key Value
|
||||
--- -----
|
||||
check_ins [fizz@example.com]
|
||||
|
|
@ -405,7 +405,7 @@ Vault will check it back in automatically when the `ttl` expires. However, if th
|
|||
service accounts can be forcibly checked in by a highly privileged user through:
|
||||
|
||||
```shell-session
|
||||
$ vault write -f auth/ldap/library/manage/accounting-team/check-in
|
||||
$ vault write -f ldap/library/manage/accounting-team/check-in
|
||||
Key Value
|
||||
--- -----
|
||||
check_ins [fizz@example.com]
|
||||
|
|
|
|||
Loading…
Reference in New Issue