Re-configuring role fails after upgrading existing deployment to Vault 1.9.x

[tsaarni]

New attribute alias_name_source was added to the "Create Role" request by following change in Vault 1.9.0

auth/kubernetes: Add ability to configure entity alias names based on the serviceaccount's namespace and name. https://github.com/hashicorp/vault-plugin-auth-kubernetes/pull/110 https://github.com/hashicorp/vault-plugin-auth-kubernetes/pull/112 [GH-12633]

Problem 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

{
    "auth": null,
    "data": {
        "alias_name_source": "",
        "bound_service_account_names": [
            "*"
        ],
        "bound_service_account_namespaces": [
            "default"
        ],
        "policies": [
            "my-policy"
        ],
        "token_bound_cidrs": [],
        "token_explicit_max_ttl": 0,
        "token_max_ttl": 0,
        "token_no_default_policy": false,
        "token_num_uses": 0,
        "token_period": 0,
        "token_policies": [
            "my-policy"
        ],
        "token_ttl": 0,
        "token_type": "default"
    },
    "lease_duration": 0,
    "lease_id": "",
    "renewable": false,
    "request_id": "c09d75a5-ceb5-1989-63cb-0e451f9e3820",
    "warnings": null,
    "wrap_info": null
}

Note that alias_name_source has value "" and not the default value serviceaccount_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 with HTTP/1.1 400 Bad Request

{
    "errors": [
        "invalid alias_name_source, must be one of: serviceaccount_uid, serviceaccount_name"
    ]
}

Expected behavior

One of the following alternatives:

1. Return "alias_name_source": "serviceaccount_uid".
2. Do not return 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.

[tsaarni]

Cc @benashz

[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.

[kalafut]

Backported to 1.9.x as part of https://github.com/hashicorp/vault-plugin-auth-kubernetes/issues/133

[benashz]

Backported to vault with https://github.com/hashicorp/vault/pull/14267 . This issue should be resolved in vault-1.9.4.