feat: added imperative get support for system-accounts

[Prashansa-K]

Summary

In this PR, we are adding get and list support for
system-account resources.
As the underlying API doesn't support labels yet,
we are just supporting read operations over these
resources.

Operations supported:

• list, list by name
• get (== list if no args are passed)
• get by name, id

Issues resolved

For #258

Documentation

• Link to the website documentation PR

Testing

• Unit tests
• E2E tests
• Manual testing on Universal
• Manual testing on Kubernetes

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Copilot]

Pull request overview

This pull request adds imperative get support for system accounts in the Konnect CLI, allowing users to retrieve and list system account information through direct commands.

Changes:

• Added SystemAccountsAPI interface and implementation in the helpers package for SDK abstraction
• Implemented get system_account command with support for listing all system accounts and fetching by ID or name
• Integrated the new command into the root-level get verb for direct access

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
internal/konnect/helpers/system_accounts.go	Defines the SystemAccountsAPI interface and implementation for listing and getting system accounts
internal/konnect/helpers/sdk_mock.go	Adds mock factory support for SystemAccountsAPI testing
internal/konnect/helpers/sdk.go	Registers the SystemAccountsAPI getter in the main SDK interface
internal/cmd/root/verbs/get/system_account.go	Creates the direct system account command with Konnect-specific flag bindings
internal/cmd/root/verbs/get/get.go	Integrates the system account command into the root get verb
internal/cmd/root/products/konnect/system_account/system_account.go	Defines the system account command structure with metadata and aliases
internal/cmd/root/products/konnect/system_account/getSystemAccount.go	Implements the core logic for listing and getting system accounts with pagination support

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[rspurgeon]

@Prashansa-K the command structure for system-accounts should fall under the konnect product, but then default to konnect. For example, to get control planes we have kongctl get konnect gateway control-planes, but as the CLI is "Konnect First by design", then kongctl get gateway control-planes works as expected.

I'm also considering the overall design of the work for these resources which currently fall under an "Identity" banner in our API but under an "Organization" banner in the product UI.

I want to structure the CLI thus (again the konnect product is implied):

kongctl get organization system-accounts
kongctl get organization teams
kongctl get organization roles
etc....

I will also be moving our kongctl get auth-strategies under kongctl get portal auth-strategies later. This should open us up to kongctl get identity later for the new Kong Identity product and hopefully keep things consistent for the user.

[Prashansa-K]

@rspurgeon I have moved the command under organization now. This works with konnect in the middle and without as well.

[rspurgeon]

@rspurgeon I have moved the command under organization now. This works with konnect in the middle and without as well.

Thanks @Prashansa-K I will review

[rspurgeon]

@Prashansa-K the structure looks good and manual tests were successful. The only thing I see missing here are some types of tests. Can we add either some integration tests or you could do an e2e scenario test. To use the e2e test scenarios, you could use the create function of the test harness. Add the resource API endpoints here:

kongctl/test/e2e/harness/step.go

Line 271 in 2ac9a17

var createResourceEndpoints = map[string]resourceEndpoint{

THen you could define a create like this:

kongctl/test/e2e/scenarios/adopt/create-portal-adopt-dump-plan/scenario.yaml

Line 13 in 2ac9a17

- name: 000-create-portal

And then build scenario asserts against the output of a test kongctl get organization sas.