Hello,
I have a question about the failure modes when issuing a write to auth/approle/login
to obtain a new client token.
For example, using the Go client and either the more low-level API per:
client.Logical().Write("auth/approle/login", map[string]interface{}{
"role_id": ...,
"secret_id": ...,
})
Or the more high-level API that abstracts some operations per:
auth, _ := approle.NewAppRoleAuth(
...,
&approle.SecretID{FromString: ...},
)
client.Auth().Login(context.TODO(), auth)
This operation usually returns a SecretAuth
type we would access to read the ClientToken
attribute from it. This works fine almost always.
However, we have seen an occasional issue where the ClientToken
attribute is absent.
This does not happen very often, but it does happen, and we have added provisions in our code to check for the presence of the relevant types to avoid a nil pointer dereference.
The typical pattern is something along the lines of the following:
secret, err := client.Logical().Write("auth/approle/login", ...)
if err != nil {
return err
}
if secret == nil || secret.Auth == nil || secret.Auth.ClientToken == "" {
return errors.New("...")
}
client.SetToken(secret.Auth.ClientToken)
The above would be different when using the more high-level API (the client.Auth().Login()
function) as this specific API internally sets the new client token for us at the client object level after performing a validation similar to the above one internally - and
should there be an error, the client.Auth().Login()
function will return a plain error with an appropriate error message.
This is all fine, of course.
That said, I would like to understand better why a “login” operation, which is just a request to retrieve a new client token upon prior authentication with some current token, can return no results (the authentication information will be missing).
Should this be considered a standard failure mode? Something that should be handled, recovered from and perhaps even retried?
Perhaps this is a side-effect of some of our Vault deployment issues? Maybe we need to up the compute sizing on which Vault runs as some performance issue is causing this?
I am asking here as I couldn’t find anything to address my question within the issues on GitHub or the documentation.
Thank you!
Krzysztof