mirror of
https://github.com/optim-enterprises-bv/vault.git
synced 2025-11-06 13:38:01 +00:00
Added a table showing the entity alias name used by each auth method. (#10908)
* Also corrected the text about token auth method.
This commit is contained in:
@@ -81,6 +81,33 @@ these identity providers. Hence, the alias name in combination with the
|
|||||||
authentication backend mount's accessor, serve as the unique identifier of an
|
authentication backend mount's accessor, serve as the unique identifier of an
|
||||||
alias.
|
alias.
|
||||||
|
|
||||||
|
The table below shows what information each of the supported auth methods uses
|
||||||
|
to form the alias name. This is the identifying information that is used to match or create
|
||||||
|
an entity. If no entities are explicitly created or merged, then one [entity will be implicitly created](#implicit-entities)
|
||||||
|
for each object on the right-hand side of the table, when it is used to authenticate on
|
||||||
|
a particular auth mount point.
|
||||||
|
|
||||||
|
| Auth method | Name reported by auth method |
|
||||||
|
| ----------- | --------------------------------------------- |
|
||||||
|
| AliCloud | Principal ID |
|
||||||
|
| AppRole | Role ID |
|
||||||
|
| AWS IAM | Configurable via `iam_alias` to one of: Role ID (default), IAM unique ID, Full ARN |
|
||||||
|
| AWS EC2 | Configurable via `ec2_alias` to one of: Role ID (default), EC2 instance ID, AMI ID |
|
||||||
|
| Azure | Subject (from JWT claim) |
|
||||||
|
| Cloud Foundry | App ID |
|
||||||
|
| GitHub | User login name associated with token |
|
||||||
|
| Google Cloud | Configurable via `iam_alias` to one of: Role ID (default), Service account unique ID |
|
||||||
|
| JWT/OIDC | Configurable via `user_claim` to one of the presented claims (no default value) |
|
||||||
|
| Kerberos | Username |
|
||||||
|
| Kubernetes | Service account UID |
|
||||||
|
| LDAP | Username |
|
||||||
|
| OCI | Constant “name” (_This is a bug in current version_) |
|
||||||
|
| Okta | Username |
|
||||||
|
| RADIUS | Username |
|
||||||
|
| TLS Certificate | Subject CommonName |
|
||||||
|
| Token | `entity_alias`, if provided |
|
||||||
|
| Username (userpass) | Username |
|
||||||
|
|
||||||
### Local Auth Methods
|
### Local Auth Methods
|
||||||
|
|
||||||
If a login is performed using an auth method that was mounted locally on a
|
If a login is performed using an auth method that was mounted locally on a
|
||||||
@@ -96,8 +123,9 @@ successful user login from any of the authentication backends, Vault will
|
|||||||
create a new entity and assign an alias against the login that was successful.
|
create a new entity and assign an alias against the login that was successful.
|
||||||
|
|
||||||
Note that the tokens created using the token authentication backend will not
|
Note that the tokens created using the token authentication backend will not
|
||||||
have an associated identity information. Logging in using the authentication
|
normally have any associated identity information. An existing or new implicit
|
||||||
backends is the only way to create tokens that have a valid entity identifiers.
|
entity can be assigned by using the `entity_alias` parameter, when creating a
|
||||||
|
token using a token role with a configured list of `allowed_entity_aliases`.
|
||||||
|
|
||||||
### Identity Auditing
|
### Identity Auditing
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user