Adds Service Accounts tab

[samuelcostae]

Description
Updated UI to make use of new separate Internal/service accounts API endpoints being added to security plugin backend via PR opensearch-project/security#2786

Differently From Internal Accounts, 'Delete' and 'Create' Buttons were removed for Service Accounts.

'Internal Users' renamed to 'Internal Accounts' to be in line with 'Service Accounts' as discussed on opensearch-project/security#2842

Category
Enhancement

Why these changes are required?
Improve UX

What is the old behavior before changes and new behavior after changes?
All accounts had to be requested, without filtering Internal/Service

Issues Resolved
#2704

Testing
Manual test on UI

Check List

• New functionality includes testing
• New functionality has been documented
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[peternied]

@samuelcostae We've got an upcoming 2.10 release and I'm reviewing outstanding pull requests, would you like this pull request to be considered for inclusion?

Some commits are missing the DCO and tests failing, is this ready to review? Let me know and I'll start to take a look

[samuelcostae]

Hi @cwperks Could you please review this once more? Thanks

[cwperks]

Hey @samuelcostae , it still feels a bit pre-mature to me to add UX but I will defer to @scrawfor99 and @peternied who have been more involved with the planning and delivery of this feature. For the first time a new feature is released like this, I think it would be appropriate to have an experimental label which implies that a future minor version can make breaking changes to the feature and that backward compatibility will not be guaranteed.

IMO I would also like to keep the terminology internal users because it is prevalently used. I see why internal accounts would be more consistent with service accounts, but internalusers is used in API routes like this: https://opensearch.org/docs/latest/security/access-control/api/#get-user

From what I understand, in the initial release, service accounts will not be very interesting from an end user perspective. They are completely restricted to a set of protected indices associated with the extension/plugin that they represent. Even if its possible to map a service account to roles, the action would not result in any new behavior granted to the service account because its restricted to a set of indices that are reserved by the corresponding plugin/extension.

---

As it pertains to this particular PR, I do see that there is an option to Edit the account. From what I understand, a service account is currently distinguished from a regular account because it has an attribute with a key of service and a value set to true. Using the UX from this PR, is it possible that an admin can hit the Edit button and demote the account to a regular account?

[samuelcostae]

Using the UX from this PR, is it possible that an admin can hit the Edit button and demote the account to a regular account?

Correct, this is currently possible. @peternied Is this something we would like hide in the front-end?

[peternied]

I don't have a strong opinion - so lets go with what @cwperks is thinking.

[samuelcostae]

@scrawfor99 friendly ping

[RyanL1997]

Hi @samuelcostae, thank you for taking this on. This is looking good to me, and I just left a very minor review/question for the folks about the renaming.

[RyanL1997]

Hi @samuelcostae , this is LGTM. I will approve it if we fix the minor formatting failure of unit test. Btw the failure of integration test is due to its flakiness.

[samuelcostae]

@DarshitChanpura seems you need to approve again after the changes :)

[DarshitChanpura]

@samuelcostae Could you look into Unit test failures?
Fixed via: #1652

[DarshitChanpura]

LGTM. @cwperks any final questions before we merge this?

[cwperks]

Same with @peternied , I don't have strong opinions so I defer to the rest of the team.

I see that there's a column for backend roles, is that something that can be added to a service account?

If extensions was further along, I would also recommend an admin page for extensions where security settings for extensions (i.e. reserved indices, other security settings) could be configured along with other settings.

[DarshitChanpura]

I see that there's a column for backend roles, is that something that can be added to a service account?

If we plan to, then let's address it in a follow-up PR @samuelcostae . As I see no more blockers, I'll merge this now.

[opensearch-trigger-bot]

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.x 2.x
# Navigate to the new working tree
cd .worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-1502-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 94961bd9a0cb78474c41440b887db23133591966
# Push it to GitHub
git push --set-upstream origin backport/backport-1502-to-2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-1502-to-2.x.

[DarshitChanpura]

@samuelcostae Could you look into 2.x backport failure