Lack of input validation with lists in CLI when missing commas

[dopheide-esnet]

Describe the bug The vault CLI allows the user to input invalid lists for policy/config attributes. There are two different results we've seen from this.

1. When inputting token_bound_cidrs for an approle, adding a list of cidrs without a comma results in complete inability to read the current approle configuration.
2. When inputting allowed_roles for a database config, inputting a list with spaces makes the roles invalid. However, whether the list is input with spaces or commas, it is always displayed with spaces making it impossible to tell where the issue is.

To Reproduce Steps to reproduce the behavior: For 1) This works fine:

vault write auth/approle/role/dop_test_role secret_id_ttl=10m token_num_uses=10 token_ttl=20m token_max_ttl=30m secret_id_num_uses=40 token_bound_cidrs="10.0.0.0/24,10.0.1.0/24" token_policies="default,root"

This next one tells you it was successful, but then you can't read the data back:

vault write auth/approle/role/dop_test_role     secret_id_ttl=10m     token_num_uses=10     token_ttl=20m     token_max_ttl=30m     secret_id_num_uses=40 token_bound_cidrs="10.0.0.0/24 10.0.1.0/24" token_policies="default,root"
Success! Data written to: auth/approle/role/dop_test_role

However, now the app_role is unreadable:

$ vault read auth/approle/role/dop_test_role

Error reading auth/approle/role/dop_test_role: Error making API request.

URL: GET https://redacted:8200/v1/auth/approle/role/dop_test_role
Code: 500. Errors:

* internal error

For 2) A bit more complex because our test case requires having a database setup. Setup is basically this if you have docker:

docker run --name vault-postgres -e POSTGRES_PASSWORD=vaulttestpassword -d postgres
docker run -it --rm postgres psql -h 172.17.0.2 -U postgres

At the psql prompt:

CREATE DATABASE vault;
GRANT ALL PRIVILEGES ON DATABASE vault TO postgres;

Now we configure the base database config and test role:

vault write database/roles/dop-role db_name="vault-db-bug" creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" default_ttl="1h" max_ttl="24h"

Now we can break it.

This works:

vault write database/config/vault-db-bug allowed_roles="default,dop-role"
vault read database/creds/dop-role

This does not:

vault write database/config/vault-db-bug allowed_roles="default dop-role"
vault read database/creds/dop-role

Error reading database/creds/dop-role: Error making API request.

URL: GET https://redacted:8200/v1/database/creds/dop-role
Code: 500. Errors:

* 1 error occurred:
    * "dop-role" is not an allowed role

In both cases they look the same in the read output, showing as separated by a space:

vault read database/config/vault-db-bug
Key                                   Value
---                                   -----
allowed_roles                         [default dop-role]
connection_details                    map[connection_url:postgresql://{{username}}:{{password}}@172.17.0.2:5432 username:postgres]
password_policy                       n/a
plugin_name                           postgresql-database-plugin
plugin_version                        n/a
root_credentials_rotate_statements    []

Expected behavior The CLI should try to check if you're inputing things without spaces and should also check that the list elements are valid cidrs in the case of the first issue.

Environment: Version 1.13.1+ent Vault v1.13.1+ent (8949fec986c7ccd4508e4689d554c4b8d182fe89), built 2023-03-23T20:09:57Z Linux Ubuntu (debian bookworm/sid)

[maxb]

FYI - the vault write CLI can be thought of as "curl, but with some nice accomodations for interacting with the general form of Vault APIs" - in particular, it has no knowledge of the specific API it is invoking - it has no idea which parameters are valid or invalid, let alone what data types they expect.

As a result, it's not really possible for the CLI to provide this kind of checking.

It would be nice if the Vault server, though, responded with warning or error messages for the CLI to display, about patterns which should be CIDRs not being, or roles that don't exist.

[dopheide-esnet]

Fair enough, I think that both makes the problem worse and hopefully easier to fix at the same time. Presumably, the API would let me input a role list of: ['valid_role','valid_role2 valid_role3'] that would break the second two. Is that correct? Obviously it'd harder to make that mistake programmatically.

[hghaf099]

@dopheide-esnet Thanks for filing this issue. Would you please confirm which Vault CLI version did you use? I cannot reproduce the same issue as reported. Though I do see that the Vault server does not verify some of the inputs.

[dopheide-esnet]

vault --version Vault v1.13.1+ent (8949fec986c7ccd4508e4689d554c4b8d182fe89), built 2023-03-23T20:09:57Z