2020-01-18 00:18:09 +00:00
- `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
2023-01-26 00:12:15 +00:00
TTL](/vault/docs/concepts/tokens#token-time-to-live-periodic-tokens-and-explicit-max-ttls)
2020-01-18 00:18:09 +00:00
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.
2020-12-17 21:53:33 +00:00
If you require the token to have the ability to create child tokens,
2020-07-03 16:00:14 +00:00
you will need to set this value to 0.
2023-03-29 20:53:16 +00:00
- `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.
2020-01-18 00:18:09 +00:00
- `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.
