1--- 2layout: "docs" 3page_title: "Upgrading to Vault 0.10.0 - Guides" 4sidebar_title: "Upgrade to 0.10.0" 5sidebar_current: "docs-upgrading-to-0.10.0" 6description: |- 7 This page contains the list of deprecations and important or breaking changes 8 for Vault 0.10.0. Please read it carefully. 9--- 10 11# Overview 12 13This page contains the list of deprecations and important or breaking changes 14for Vault 0.10.0 compared to 0.9.0. Please read it carefully. 15 16## Changes Since 0.9.6 17 18### Database Plugin Compatibility 19 20The database plugin interface was enhanced to support some additional 21functionality related to root credential rotation and supporting templated 22URL strings. The changes were made in a backwards-compatible way and all 23builtin plugins were updated with the new features. Custom plugins not built 24into Vault will need to be upgraded to support templated URL strings and 25root rotation. Additionally, the Initialize method was deprecated in favor 26of a new Init method that supports configuration modifications that occur in 27the plugin back to the primary data store. 28 29### Removal of Returned Secret Information 30 31For a long time Vault has returned configuration given to various secret 32engines and auth methods with secret values (such as secret API keys or 33passwords) still intact, and with a warning to the user on write that anyone 34with read access could see the secret. This was mostly done to make it easy for 35tools like Terraform to judge whether state had drifted. However, it also feels 36quite un-Vault-y to do this and we've never felt very comfortable doing so. In 370.10 we have gone through and removed this bevhavior from the various backends; 38fields which contained secret values are simply no longer returned on read. We 39are working with the Terraform team to make changes to their provider to 40accommodate this as best as possible, and users of other tools may have to make 41adjustments, but in the end we felt that the ends did not justify the means and 42we needed to prioritize security over operational convenience. 43 44### LDAP Auth Method Case Sensitivity 45 46We now treat usernames and groups configured locally for policy assignment in a 47case insensitive fashion by default. Existing configurations will continue to 48work as they do now; however, the next time a configuration is written 49`case_sensitive_names` will need to be explicitly set to `true`. 50 51### TTL Handling Moved to Core 52 53All lease TTL handling has been centralized within the core of Vault to ensure 54consistency across all backends. Since this was previously delegated to 55individual backends, there may be some slight differences in TTLs generated 56from some backends. 57 58### Default `secret/` Mount is Deprecated 59 60In 0.12 we will stop mounting `secret/` by default at initialization time (it 61will still be available in `dev` mode). 62 63## Full List Since 0.9.0 64 65### Change to AWS Role Output 66 67The AWS authentication backend now allows binds for inputs as either a 68comma-delimited string or a string array. However, to keep consistency with 69input and output, when reading a role the binds will now be returned as string 70arrays rather than strings. 71 72### Change to AWS IAM Auth ARN Prefix Matching 73 74In order to prefix-match IAM role and instance profile ARNs in AWS auth 75backend, you now must explicitly opt-in by adding a `*` to the end of the ARN. 76Existing configurations will be upgraded automatically, but when writing a new 77role configuration the updated behavior will be used. 78### Backwards Compatible CLI Changes 79 80This upgrade guide is typically reserved for breaking changes, however it 81is worth calling out that the CLI interface to Vault has been completely 82revamped while maintaining backwards compatibility. This could lead to 83potential confusion while browsing the latest version of the Vault 84documentation on vaultproject.io. 85 86All previous CLI commands should continue to work and are backwards 87compatible in almost all cases. 88 89Documentation for previous versions of Vault can be accessed using 90the GitHub interface by browsing tags (eg [0.9.1 website tree](https://github.com/hashicorp/vault/tree/v0.9.1/website)) or by 91[building the Vault website locally](https://github.com/hashicorp/vault/tree/v0.9.1/website#running-the-site-locally). 92 93### `sys/health` DR Secondary Reporting 94 95The `replication_dr_secondary` bool returned by `sys/health` could be 96misleading since it would be `false` both when a cluster was not a DR secondary 97but also when the node is a standby in the cluster and has not yet fully 98received state from the active node. This could cause health checks on LBs to 99decide that the node was acceptable for traffic even though DR secondaries 100cannot handle normal Vault traffic. (In other words, the bool could only convey 101"yes" or "no" but not "not sure yet".) This has been replaced by 102`replication_dr_mode` and `replication_perf_mode` which are string values that 103convey the current state of the node; a value of `disabled` indicates that 104replication is disabled or the state is still being discovered. As a result, an 105LB check can positively verify that the node is both not `disabled` and is not 106a DR secondary, and avoid sending traffic to it if either is true. 107 108 109### PKI Secret Backend Roles Parameter Types 110 111For `ou` and `organization` in role definitions in the PKI secret backend, 112input can now be a comma-separated string or an array of strings. Reading a 113role will now return arrays for these parameters. 114 115### Plugin API Changes 116 117The plugin API has been updated to utilize golang's context.Context package. 118Many function signatures now accept a context object as the first parameter. 119Existing plugins will need to pull in the latest Vault code and update their 120function signatures to begin using context and the new gRPC transport. 121 122### AppRole Case Sensitivity 123 124In prior versions of Vault, `list` operations against AppRole roles would 125require preserving case in the role name, even though most other operations 126within AppRole are case-insensitive with respect to the role name. This has 127been fixed; existing roles will behave as they have in the past, but new roles 128will act case-insensitively in these cases. 129 130### Token Auth Backend Roles Parameter Types 131 132For `allowed_policies` and `disallowed_policies` in role definitions in the 133token auth backend, input can now be a comma-separated string or an array of 134strings. Reading a role will now return arrays for these parameters. 135 136### Transit Key Exporting 137 138You can now mark a key in the `transit` backend as `exportable` at any time, 139rather than just at creation time; however, once this value is set, it still 140cannot be unset. 141 142### PKI Secret Backend Roles Parameter Types 143 144For `allowed_domains` and `key_usage` in role definitions in the PKI secret 145backend, input can now be a comma-separated string or an array of strings. 146Reading a role will now return arrays for these parameters. 147 148### SSH Dynamic Keys Method Defaults to 2048-bit Keys 149 150When using the dynamic key method in the SSH backend, the default is now to use 1512048-bit keys if no specific key bit size is specified. 152 153### Consul Secret Backend Lease Handling 154 155The `consul` secret backend can now accept both strings and integer numbers of 156seconds for its lease value. The value returned on a role read will be an 157integer number of seconds instead of a human-friendly string. 158 159### Unprintable Characters Not Allowed in API Paths 160 161Unprintable characters are no longer allowed in names in the API (paths and 162path parameters), with an extra restriction on whitespace characters. Allowed 163characters are those that are considered printable by Unicode plus spaces. 164