[Question] How should we handle token generation and passing for service accounts?

[stephen-crawford]

As a follow-up to #2594, we need to decide how to create auth credentials for a service account. We have a newly added token generator as part of #2567. However, this generator may not be the best option for handling the passing of service account information back to core and then to an extension.

Specifically, there are a couple issues:

1. The new generator uses the User.java class which is not directly compatible with the Internal User model. This means that using it would require the creation of a 'Token Generator' User or something similar to then be used to fetch role information for the extensions and populate the rest of the User fields. These details could then be processed into a token. This is doable but not necessary the most straightforward process.
2. The second issue if we use the token generator is that the tokens that the generator issues are set with an expiry time. This is normally fine, but in the case of the auth tokens being passed back to core or an extension, an issue arises if the permissions change after the token is issued but before the token has expired. In this case, the token may reflect incorrect information and grant the service account inaccurate privileges. In order to handle this, we would need to implement some form of token revocation. This is not a trivial process. It is doable but not easy.

An alternative to using the token generator as is, is to place an intermediary step in the token generator process. In the alternative, we could use a token to encrypt basic auth credentials for the service account. Then the roles of the service account would be resolved at the time that the request was processed. This would fix the second issue mentioned above. It would also indirectly fix the first issue, since in this scenario we would likely want to write a different type of token generator since the current implementation is more complex then this use case. Unfortunately, this option also has its drawbacks:

1. Service accounts need to be able to be created without manual control. When an extension is registered, we need to be able to create a service account for it without requesting the cluster administrator chose a password for each extension. This means we need to generate passwords for the accounts. This is doable on a pseudo-random basis. However, the next issue is that we then need to be able to store these passwords without directly storing them as part of the internal user service account. This would be a poor security implementation so we will need to be able to store passwords in another way. We can store the hash for the passwords but then the question becomes, how do we generate the token to return to core? We need to be able to generate a token containing the account name and password (so it can be hashed and then the hash compared to the stored hash of the account) without storing the password itself. It is not clear how to do this. Perhaps we can reset the password every time core requests a token and give it a new token each time which has the encoded password?

[stephen-crawford]

[Triage] This issue is part of the ongoing work with the extensions project.

[stephen-crawford]

Decision: Option 2 (encrypting Basic Auth info) is being used as part of P0.