The Vault SSH secrets engine presently supports specifying allowed key
sizes in a field of type map[string]int. The notable limitation of this
type is that it cannot handle algorithms for which multiple key lengths
are allowed, e.g., allowing both 2048 and 4096-bit RSA keys. It relies
on parseutil to handle this conversion (for each element of the map,
calling ParseInt(...)).
A better type is map[string][]int; this allows explicitly specifying
multiple allowed key lengths and giving flexibility to the operator over
whether or not to restrict uncommon or intermediate key sizes (e.g.,
prohibiting 3072-bit RSA keys if certain deployed implementations are
not compatible -- though this is unlikely in practice).
While the SSH module can maintain this parsing logic, it'd be nice to
include it in parseutil instead. Here, we wish to remain backwards
compatible and relatively flexible in what we accept; elsewhere in the
API we use comma-separated lists of strings (e.g., allowed_domains in
the PKI secrets engine), so it makes sense to do the same here, in
addition to slices of int-like types or just a bare single int-ish.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
The Vault SSH secrets engine presently supports specifying allowed key sizes in a field of type
map[string]int. The notable limitation of this type is that it cannot handle algorithms for which multiple key lengths are allowed, e.g., allowing both 2048 and 4096-bit RSA keys. It relies onparseutilto handle this conversion (for each element of the map, callingParseInt(...)).A better type is
map[string][]int; this allows explicitly specifying multiple allowed key lengths and giving flexibility to the operator over whether or not to restrict uncommon or intermediate key sizes (e.g., prohibiting 3072-bit RSA keys if certain deployed implementations are not compatible -- though this is unlikely in practice).While the SSH module can maintain this parsing logic, it'd be nice to include it in
parseutilinstead. Here, we wish to remain backwards compatible and relatively flexible in what we accept; elsewhere in the API we use comma-separated lists of strings (e.g., allowed_domains in the PKI secrets engine), so it makes sense to do the same here, in addition to slices ofint-like types or just a bare singleint-ish.Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>Related PR: https://github.com/hashicorp/vault/pull/13991