Closed tsaarni closed 2 years ago
Cc @benashz
Hi @tsaarni , sorry to hear that you ran into this issue. A quick work around would be to omit data.alias_name_source
from your input. The subsequent read will have data.alias_name_source
set to the default.
Backported to 1.9.x as part of https://github.com/hashicorp/vault-plugin-auth-kubernetes/issues/133
Backported to vault with https://github.com/hashicorp/vault/pull/14267 . This issue should be resolved in vault-1.9.4.
New attribute
alias_name_source
was added to the "Create Role" request by following change in Vault 1.9.0Problem Description
Assume we had Role configured prior Vault 1.9.0. Obviously the existing Roles do not have this new attribute stored in the configuration. When sending "Read Role" request for such Role with the missing attribute, the output will look like
Note that
alias_name_source
has value""
and not the default valueserviceaccount_uid
.Note also that
""
is not a valid choise. Valid choices are:serviceaccount_uid
,serviceaccount_name
.This can cause problems when one attempts to apply a change to existing Role by copying the
data
from "Read Role" response, and using it as input for "Create Role" request. It contains invalid parameter"alias_name_source": ""
which will fail withHTTP/1.1 400 Bad Request
Expected behavior
One of the following alternatives:
"alias_name_source": "serviceaccount_uid"
.alias_name_source
attiribute in "Read Role" response.Maybe (1) is better, since that is aligned how Role would get stored now if creating Role from scratch on Vault 1.9+, without specifying the attribute in Create Role.