Secure remote access with MFA
Multi-Factor Authentication (MFA) is a system that requires more than one form of authentication to verify the identity of a user for a login or transaction. Typically implemented for governing human access to a system, MFA works by requiring any two or more of the following verification methods:
- Something the user knows (their password)
- Something the user owns (security token, one-time code, push notification)
- Something the user is (biometric information such as their fingerprint or retinal pattern)
Vault MFA capabilities
Vault incorporates two types of MFA:
- Login MFA - Additional layers of security to login workflows
- Vault Enterprise “step up” MFA - An enhanced security layer to protect sensitive API endpoints.
1. Login MFA via OpenID Connect (OIDC) or external identity provider
Many external identity providers (IDPs) like Okta or Ping Identity enable login multi-factor authentication (MFA) on their platforms. While MFA methods vary across providers, they typically mandate MFA verification during the authentication process, before granting access to applications. If an identity provider supports the OpenID Connect (OIDC) protocol, you can set up Vault's OIDC authentication method as outlined below. This setup ensures that users must complete the MFA process established at the IDP level for Vault access.
Figure 1: OIDC Auth with MFA Workflow
This approach is preferred when the IDP supports MFA because it allows you to keep all human identity management, access control, and MFA configurations in one place. It also provides scalability as your organization grows. MFA for login will only need to be configured in one place (the IDP) as opposed to separately setting up MFA in a consuming application such as Vault.
Vault Login MFA with LDAP and TOTP
The Vault operating guide HVD specifies two different human authentication methods that can be configured for organization-wide human access to Vault: OIDC and LDAP (Lightweight Directory Access Protocol). While many OIDC-compliant IDPs support implementing MFA at the identity provider level, it is less common for LDAP providers to offer native MFA support. In cases where an LDAP provider doesn't support MFA, Vault allows for MFA configurations through the LDAP method with Time-Based One-Time Password (TOTP). TOTP requires configuring a pre-shared key between Vault and a client mobile application or hardware device. The client uses a combination of the pre-shared key and the current time to generate a unique code that is only valid for a specific amount of time. This code is used as the additional factor to complete login.
Although TOTP is usually the best method when an external provider is not available, Vault also integrates with other platforms like Okta or Ping. However, it's worth noting that if Okta or Ping is accessible, the recommended approach is to configure MFA at the IDP level instead of separately within Vault to maintain unified access control and ease of management.
Due to the enrollment process involving sharing a key between Vault and an end-user’s mobile device, the TOTP method is not suitable for enrolling large numbers of users. It is therefore recommended to implement TOTP with LDAP authentication on the relatively smaller number of highly privileged users (Super administrators and regular administrators) to protect their access to Vault.
To utilize this method, a TOTP MFA method needs to be configured in Vault and associated with the organization LDAP auth method. Each user will need to enroll their device with a pre-shared key generated by Vault.
Configuration
The steps for configuration of TOTP MFA enforcement on an LDAP auth mount are listed below. Note that steps 3 and 4 will need to be repeated for each user that needs TOTP MFA setup.
Step 1: Enable the LDAP auth method
Enable LDAP prior to TOTP configuration. Refer to the Vault Operating Guide or adopting HVD document to configure LDAP authentication for your organization.
Step 2: Enable login MFA method
Enable a Login MFA method.
Note the method_id that is returned by Vault. This ID will be required to generate a QR code that will configure an end-user TOTP device.
**NOTE: **Consider the algorithms supported by your end-user authenticator application. For example, Google Authenticator for Android supports only SHA1 as the value of the algorithm. The Vault MFA API defaults to the SHA1 algorithm, if no value is supplied during configuration.
Step 3: Login with the user for which MFA should be configured
The user who needs to have MFA configured should log in to Vault.
Look up the user’s token properties to capture the user’s entity_id generated by Vault.
Step 4: Generate a TOTP setup QR code
Generate a PNG image of the TOTP QR code for the user. This QR Code should be scanned by the appropriate user with a TOTP generation app such as Google Authenticator. Use the TOTP method_id and user entity_id noted earlier.
Delete the QR Code image after the scanning process is complete.
Step 5: Enforce MFA on LDAP login
In order to enable MFA enforcement, you will need the accessor value of the LDAP auth mount as well as the TOTP method_id noted earlier. Capture the accessor value for the LDAP auth method mount.
Create the enforcement by tying the MFA method_id to the LDAP auth mount accessor.
Step 6: Test MFA enforcement on LDAP auth method
Test the enforcement of TOTP MFA on the LDAP auth method by logging in with the Vault CLI.
2.Vault Enterprise Step Up MFA
Vault Enterprise and HCP Vault feature a “step up” MFA workflow that requires a user to present an additional identity factor when issuing specific API requests, even if they have already successfully authenticated to Vault.
Guidance: In a situation where highly critical secrets are stored in Vault for human users to access, it is recommended to implement a step up MFA policy that provides additional security and identity assurance on highly critical secrets in Vault.
**Note: **Enterprise “step up” MFA cannot be configured on HCP Vault, the sys/mfa/ path is only accessible from the root namespace, which is not available to the end user in HCP Vault.
For example, if a static secret were stored at the key value path secret/topsecret/data/foo, a “step-up” MFA policy could be configured to require that any authenticated user accessing the path complete an MFA workflow, prior to being granted access to the secret. This provides additional assurance that the user accessing the path is the same user that originally authenticated, and that their Vault token has not been compromised.
For “step-up” MFA, Vault supports TOTP, Okta push notification, Duo push notification, and PIngID push notification methods. For ease of enrollment, it can be useful to leverage any pre-existing IDP MFA capabilities that may exist in your environment. However, if there are no IDP provided MFA methods available, it is recommended to implement TOTP MFA in Vault.
Configuration
This section will cover configuration of TOTP for “step-up” MFA in Vault. For other methods, steps 1, 2, and 3 will differ. However, steps 4 and 5, which link the MFA method to a specific Vault ACL policy, will remain the same for other MFA methods.
The configuration steps below assume that you already have a human auth method such as OIDC or LDAP configured on your Vault instance. Note that step 2 and 3 will need to be repeated for each user that needs to enroll in TOTP.
Step 1: Configure the TOTP MFA method
Create a TOTP MFA method that will be referenced in a Vault ACL policy to limit access to sensitive secrets.
**NOTE: **Consider the algorithms supported by your end-user authenticator application. For example, Google Authenticator for Android supports only SHA1 as the value of the algorithm. The Vault MFA API defaults to the SHA1 algorithm, if no value is supplied during configuration.
Make a note of the id that is returned by Vault from the read command. This ID will be required to generate a QR code that will configure an end-user TOTP device.
Step 2: Login with the user for which MFA should be configured
The user who needs to have MFA configured should log in to Vault.
Lookup the user’s token properties to capture the user’s entity_id generated by Vault.
Step 3: Generate a TOTP setup QR code
Generate a PNG image of the TOTP setup barcode for the user. This QR code should be scanned by the appropriate user with a TOTP generation app such as Google Authenticator. Use the TOTP method_id and user entity_id noted earlier.
Delete the QR image after the scanning process is complete.
Step 4: Create policy enforcing MFA method on sensitive secret
Create a policy that gates access to a sensitive secret through the previously created MFA method.
Note that this policy will need to be applied to the appropriate users who should have access to this secret. Configure the appropriate auth method and/or role to assign this policy to the appropriate users.
Step 5: Test accessing the secret
When reading the secret, the mfa flag needs to be supplied containing the appropriate TOTP code, otherwise Vault will not grant access to the secret.