mirror of
https://github.com/hashicorp/vault.git
synced 2025-08-23 23:51:08 +02:00
c4be16c8f7
* Update the page description to improve SEO * Minor updates * Update setup.mdx * Update setup.mdx * Update website/content/docs/secrets/ad/migration-guide.mdx Co-authored-by: Jonathan Frappier <92055993+jonathanfrappier@users.noreply.github.com> * Update website/content/docs/secrets/ad/index.mdx Co-authored-by: Jonathan Frappier <92055993+jonathanfrappier@users.noreply.github.com> * Update website/content/docs/secrets/ad/index.mdx Co-authored-by: Jonathan Frappier <92055993+jonathanfrappier@users.noreply.github.com> --------- Co-authored-by: Jonathan Frappier <92055993+jonathanfrappier@users.noreply.github.com>
50 lines
2.4 KiB
Plaintext
50 lines
2.4 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.
|
|
---
|
|
|
|
# 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.
|