[FEA]: Usage of auth-tokens instead of username+password in services that interact with BMCs

[Matthias247]

Within the service, various microservices interact with BMCs:

• core
• serial-console
• hw-health
• rms

All of them receive BMC credentials via certain APIs from the core service.

In order to limit the visibility of long-lived credentials, the services should be converted to use auth tokens, as provided by the redfish session service: https://www.dmtf.org/sites/default/files/Redfish_School-Sessions.pdf.

• A process within core would authenticate against BMCs and generate session tokens
• These session tokens would be shared with all consumers
• Session tokens should be short-lived and get rotated. For each consumer there need to be at least 2 active tokens (current and next).

This approach requires the BMCs to support session APIs. If they are not available, the fallback option is to still share username and password for the affected hardware components.

[yoks]

On roadmap for https://github.com/NVIDIA/nv-redfish, almost exactly like you described.

While creating BMC it would accept credentials, after that it would discover if SessionService is available and session tokens are exists. It would then handle session via session token.

Important caveat is token themselves can be very long lived, and should be explicitly revokated (logout).

There is two use cases:

1. use nv-redfish AuthenticatedBMC, but it would assume every service will still need to use credentials to obtain them, good thing is you can track every session and every service, as well as logout logic is contained withing service
2. only core handle credentials, in this case core need to implement credentials revocation

[Matthias247]

My main goal would be to limit credential sharing between multiple services. And thereby only one nv-redfish instance should do the session management. And all the others should never log in, but just use the tokens that they get passed externally.

[yoks]

Ok so to get it done core need module which handles session tokens? It should issue tokens and logout them (on timer?).

Not sure about current/next thing tho. If token expires/revoked service can ask for next token via API. Also there is no way to issue token in future, so Next token will work just for longer lifetime.

I think best case is just:

1. issue token
2. revoke them on timer

And let services handle token refresh. Latency should not be a big issue, as BMC is slow in general.

[Matthias247]

Not sure about current/next thing tho. If token expires/revoked service can ask for next token via API. Also there is no way to issue token in future, so Next token will work just for longer lifetime.

I'd expect the consumers (like hw-health) to just periodically query for tokens. And they would use the latest they get.

and then

• The issuer of the tokens needs to work on establishing a new session at some time before the old token expires
• As soon as a new token is available, the GetCredentials calls would return the new tokens
• then later on, after the typical refresh intervals of consumers, the refresh component would close the old sessions