* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
3.5 KiB
layout | page_title | sidebar_title | sidebar_current | description |
---|---|---|---|---|
docs | MFA Support - Vault Enterprise | MFA | docs-vault-enterprise-mfa | Vault Enterprise has support for Multi-factor Authentication (MFA), using different authentication types. |
Vault Enterprise MFA Support
Vault Enterprise has support for Multi-factor Authentication (MFA), using different authentication types. MFA is built on top of the Identity system of Vault.
MFA Types
MFA in Vault can be of the following types.
-
Time-based One-time Password (TOTP)
- If configured and enabled on a path, this would require a TOTP passcode along with Vault token, to be presented while invoking the API request. The passcode will be validated against the TOTP key present in the identity of the caller in Vault. -
Okta
- If Okta push is configured and enabled on a path, then the enrolled device of the user will get a push notification to approve or deny the access to the API. The Okta username will be derived from the caller identity's alias. -
Duo
- If Duo push is configured and enabled on a path, then the enrolled device of the user will get a push notification to approve or deny the access to the API. The Duo username will be derived from the caller identity's alias. -
PingID
- If PingID push is configured and enabled on a path, then the enrolled device of the user will get a push notification to approve or deny the access to the API. The PingID username will be derived from the caller identity's alias.
Configuring MFA Methods
MFA methods are globally managed within the System Backend
using the HTTP API.
Please see MFA API for details on how to configure an MFA
method.
MFA Methods In Policies
MFA requirements on paths are specified as mfa_methods
along with other ACL
parameters.
Sample Policy
path "secret/foo" {
capabilities = ["read"]
mfa_methods = ["dev_team_duo", "sales_team_totp"]
}
The above policy grants read
access to secret/foo
only after both the MFA
methods dev_team_duo
and sales_team_totp
are validated.
Namespaces
All MFA configurations must be configured in the root namespace. They can be referenced from ACL and Sentinel policies in any namespace via the method name and can be tied to a mount accessor in any namespace.
When using Sentinel
EGPs,
any MFA configuration specified must be satisfied by all requests affected by
the policy, which can be difficult if the configured paths spread across
namespaces. One way to address this is to use a policy similar to the
following, using or
operators to allow MFA configurations tied to mount
accessors in the various namespaces:
import "mfa"
has_mfa = rule {
mfa.methods.duons1.valid
}
has_mfa2 = rule {
mfa.methods.duons2.valid
}
main = rule {
has_mfa or has_mfa2
}
When using TOTP, any user with ACL permissions can self-generate credentials. Admins can generate or destroy credentials only if the targeted entity is in the same namespace.
Supplying MFA Credentials
MFA credentials are retrieved from the X-Vault-MFA
HTTP header. The format of
the header is mfa_method_name[:key[=value]]
. The items in the []
are
optional.
Sample Request
$ curl \
--header "X-Vault-Token: ..." \
--header "X-Vault-MFA:my_totp:695452" \
http://127.0.0.1:8200/v1/secret/foo
API
MFA can be managed entirely over the HTTP API. Please see MFA API for more details.