Constraints and limitations
No access to root namespace
The root namespace is reserved for platform operations and is not customer accessible. Refer to the Manage tenants with Vault namespaces tutorial for a walkthrough of managing namespaces with HCP Vault Dedicated.
Vault system API
Most endpoints under /v1/sys that require authentication are not available. An
exception has been made for the following endpoints:
Admin token policy
The admin policy used to generate admin tokens is located in the customer admin namespace
and is named hcp-root. Although this policy is editable by the customer in their namespace, it should not
be edited. If needed, this policy will be updated to the general admin policy by HCP Vault Dedicated, and all customizations by the user are removed.
By editing this policy, admin tokens will not act as root tokens in the namespace
and you will be restricted from performing all operations. In the future, we plan to limit the modifications of this policy
and/or regenerate this policy before generating an admin token. Currently, the recovery of this policy is manual for
the HCP operators and may delay recovery of your Vault cluster.
Workload identity federation for Vault
Workload identity federation (WIF) is not currently supported for Vault auth methods and secrets engines.
Note
This limitation does not affect workload identity federation for the HashiCorp Cloud Platform.
Integrated Storage only
HCP Vault Dedicated only supports raft integrated storage, and cannot be reconfigured to use Consul as a storage backend.
TLS certificate authentication
Not available by default. When the TLS auth method is enabled for HCP Vault Dedicated and the cluster's Vault UI is accesed via web browser, users may see a popup to select a client certificate. The pop-up can be closed and the Vault UI can still be accessed. To use the TLS authentication method in HCP Vault Dedicated, please submit a support request here to have the feature enabled.
AWS Cross Account Setup
Not available by default. HCP Vault Dedicated on AWS can support cross-account access for the AWS authentication method and AWS secrets engine, please submit a support request here to have the feature enabled.
External storage for tokenization
The Transform Secrets Engine is available on HCP Vault Dedicated Plus tier clusters, but external storage for tokenization is not supported at this time.
Diagnostic logs
Vault diagnostic (e.g. server) logs are not accessible to HCP Vault Dedicated customers today. If you require assistance from the Support Team to help you troubleshoot a specific diagnostic issue, you can open a support ticket.
External plugins
The Oracle Database Secrets Engine and HashiCorp Partner Plugins are the only external plugin currently available in HCP Vault Dedicated. HCP Vault Dedicated does not currently support user provided external Vault plugins. If you'd like to see future support of additional plugins on HCP Vault Dedicated, please share feedback here.
Rate limits
Request rate limits are enforced on certain instance sizes. The response message for rate limit enforcement will be similar to this example:
See this article for more detail.
Sentinel and Control Groups
Sentinel policies and Control Groups, part of Vault's governance and policy features, are only available for Plus tier HCP Vault clusters. If you are using these features and need to scale your cluster to a different tier, it is recommended to delete existing Sentinel policies and remove any control group settings within existing ACL policies within your Vault instance. These features will only work in Plus tier clusters.'
If a Sentinel policy prevents admin token generation for your cluster, please file a support ticket here to have the offending policy deleted.
KMIP secrets engine
All ADP features, including the KMIP secrets engine, are only available for Plus tier HCP Vault clusters. The KMIP listener can only be configured to the default port (5696).
Namespace API lock constraints
When using the Namespace API lock functionality through the UI there are some limitations:
- Not possible to lock/unlock the cluster when its state is different than RUNNING/LOCKED.
- In the performance replication scenario, it's not possible to lock/unlock a secondary directly, you should instead operate on the primary which will then replicate the lock status to the secondary.
- Additionally, it's not possible to lock/unlock the primary when the secondary is not RUNNING/LOCKED.