Add Extension Service Accounts

[stephen-crawford]

Problem Statement

Based on the discussions on decision document review and comment discussions, I am moving forward with implementing service accounts for Extensions.

As part of implementing service accounts, there are several individual items that will need to be addressed.

Specifically the Security Plugin:

• Needs to know what extensions exist
• Needs to know how to make a service account
• Needs to be able to give the service account to an extension

After addressing these items, the a mock up of a service account can be provided. The mock up will include details on how the Security Plugin can authenticate a service account and how a service account is treated differently than a user account.

$\textcolor{cyan}{\textsf{Needs to know what extensions exist}}$

For the Security Plugin to know what extensions exist, we can just implement a new API similar to the existing _cat/plugins API. this will allow the Security Plugin to know which extensions are installed.

The other alternative would be to parse the service accounts to find the extensions associated with each but this would be a costly process taking O(n) to resolve a single extension.

You could alternatively inject the Extensions Manager into the Guice Holder for the Security Plugin.

Until proven otherwise, it appears to make much more sense to choose the first option.

$\textcolor{cyan}{\textsf{Needs to know how to make a service account}}$

When an extension is installed, we will want core to share information about the extension with the Security Plugin. The Security Plugin can then use that information to create a service account for the extension along the lines of the comments on this issue and this write up.

$\textcolor{cyan}{\textsf{Needs to be able to give the service account to the extension}}$

After a service account is created for an extension, the Security Plugin will need to give that account to the extension. The most straightforward way of doing this is by sending the service account credentials back to core and then having core provide those details to the extension as part of the installation process. There is not a clear alternative to this solution since the extension will not actually be speaking directly with the Security Plugin at any point of installation.

[cwperks]

@scrawfor99 It should be possible to inject the ExtensionsManager to get the list of installed extensions which updates as new extensions are installed as well. Anything binded in Node.java is injectable: https://github.com/opensearch-project/OpenSearch/blob/main/server/src/main/java/org/opensearch/node/Node.java#L1020

You can inject it into the GuiceHolder here: https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/OpenSearchSecurityPlugin.java#L1172-L1179

---

We should scope out work items to identify everything that needs to be done for service accounts and service account tokens. The tokens are intended for extensions that require a system index to be able to interact with their system index including creation and deletion of an index since index patterns are permitted with system index registration.

One option is re-using the internalusers and making a special type of user that could be identified with service: true (similar to reserved: true).

Service accounts should have special validation:

• Service accounts are passwordless - you cannot login to OSD using a service account
• Service accounts are mapped to at most 1 role
• Service accounts cannot be assigned backend roles

Likewise, there should probably be APIs specific to service accounts similar to internalusers, but respect these restrictions.

Service accounts only become useful when a token is created for the service account. That token could be used on behalf of the service account and the scope of that token would be the permissions of the single role that the service account is associated with if its associated with a role.

For the extensions use-case, for extensions that interact with a system index this token would permit it to create and delete indices matching the pattern of the registered index and allow it to index documents and search on the registered index pattern.

APIs need to be developed to create a token, invalidate a token and list all tokens for the service account.

[stephen-crawford]

Hi @cwperks, thank you for your detailed comment.

I will take a look at the ExtensionManager now and see what would be required to grab the list of installed extensions and inject it to the GuiceHolder.

To the second part of your comment, I agree that we will need to scope out the specifics of what is required of and by service accounts. For the time being, I plan to do this in a POC form in order to get some concrete implementations down. I think that it is safe to start with a POC PR and leave notes where things require further decision making. In my opinion this can be an effective development strategy since it is possible to iterate while also progressing onwards with the end goal in sight.

[stephen-crawford]

Closing in favor of #2594.