| - `token_bound_cidrs` `(array: [] or comma-delimited string: "")` - List of |
| CIDR blocks; if set, specifies blocks of IP addresses which can authenticate |
| successfully, and ties the resulting token to these blocks as well. |
| - `token_explicit_max_ttl` `(integer: 0 or string: "")` - If set, will encode |
| an [explicit max |
| TTL](/vault/docs/concepts/tokens#token-time-to-live-periodic-tokens-and-explicit-max-ttls) |
| onto the token. This is a hard cap even if `token_ttl` and `token_max_ttl` |
| would otherwise allow a renewal. |
| - `token_no_default_policy` `(bool: false)` - If set, the `default` policy will |
| not be set on generated tokens; otherwise it will be added to the policies set |
| in `token_policies`. |
| - `token_num_uses` `(integer: 0)` - The maximum number of times a generated |
| token may be used (within its lifetime); 0 means unlimited. |
| If you require the token to have the ability to create child tokens, |
| you will need to set this value to 0. |
| - `token_period` `(integer: 0 or string: "")` - The maximum allowed [period](/vault/docs/concepts/tokens#token-time-to-live-periodic-tokens-and-explicit-max-ttls) value when a periodic token is requested from this role. |
| - `token_type` `(string: "")` - The type of token that should be generated. Can |
| be `service`, `batch`, or `default` to use the mount's tuned default (which |
| unless changed will be `service` tokens). For token store roles, there are two |
| additional possibilities: `default-service` and `default-batch` which specify |
| the type to return unless the client requests a different type at generation |
| time. |
