mirror of
https://github.com/hashicorp/vault.git
synced 2025-08-22 23:21:08 +02:00
0660ea6fac
* Update README Let contributors know that docs will now be located in UDR * Add comments to each mdx doc Comment has been added to all mdx docs that are not partials * chore: added changelog changelog check failure * wip: removed changelog * Fix content errors * Doc spacing * Update website/content/docs/deploy/kubernetes/vso/helm.mdx Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com> --------- Co-authored-by: jonathanfrappier <92055993+jonathanfrappier@users.noreply.github.com> Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
53 lines
2.9 KiB
Plaintext
53 lines
2.9 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Identity secrets engine
|
|
description: >-
|
|
Manage Vault client identities with the identity secrets engine. An entity represents a unique client which can have multiple aliases tied back to it.
|
|
---
|
|
|
|
> [!IMPORTANT]
|
|
> **Documentation Update:** Product documentation, which were located in this repository under `/website`, are now located in [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs), colocated with all other product documentation. Contributions to this content should be done in the `web-unified-docs` repo, and not this one. Changes made to `/website` content in this repo will not be reflected on the developer.hashicorp.com website.
|
|
|
|
# Identity secrets engine
|
|
|
|
The identity secrets engine is the identity management solution for Vault. It
|
|
internally maintains the clients who are recognized by Vault. Each client is
|
|
internally termed as an `Entity`. An entity can have multiple `Aliases`. For
|
|
example, a single user who has accounts in both GitHub and LDAP, can be mapped
|
|
to a single entity in Vault that has 2 aliases, one of type GitHub and one of
|
|
type LDAP. When a client authenticates successfully via any of the credential backends
|
|
(except the Token backend), Vault creates a new entity and attaches a new
|
|
alias to it, if a corresponding entity doesn't already exist. The entity identifier will
|
|
be tied to the authenticated token. When such tokens are put to use, their
|
|
entity identifiers are audit logged, marking a trail of actions performed by
|
|
specific users.
|
|
|
|
Identity store allows operators to **manage** the entities in Vault. Entities
|
|
can be created and aliases can be tied to entities, via the ACL'd API. There
|
|
can be policies set on the entities which adds capabilities to the tokens that
|
|
are tied to entity identifiers. The capabilities granted to tokens via the
|
|
entities are **an addition** to the existing capabilities of the token and
|
|
**not** a replacement. The capabilities of the token that get inherited from
|
|
entities are computed dynamically at request time. This provides flexibility in
|
|
controlling the access of tokens that are already issued.
|
|
|
|
~> **NOTE:** This secrets engine will be mounted by default. This secrets engine
|
|
cannot be disabled or moved. For more conceptual overview on identity, refer to
|
|
the [Identity](/vault/docs/concepts/identity) documentation.
|
|
|
|
The Vault Identity secrets engine supports several different features. Each
|
|
one is individually documented on its own page.
|
|
|
|
- [Identity tokens](/vault/docs/secrets/identity/identity-token)
|
|
- [OIDC Identity Provider](/vault/docs/secrets/identity/oidc-provider)
|
|
|
|
## API
|
|
|
|
The Identity secrets engine has a full HTTP API. Please see the
|
|
[Identity secrets engine API](/vault/api-docs/secret/identity) for more
|
|
details.
|
|
|
|
Additionally, Vault can be configured as an OIDC identity provider. Please see
|
|
the [OIDC identity provider API](/vault/api-docs/secret/identity/oidc-provider) for
|
|
more details.
|