[mbevc1]

Adds a --personal flag to kosli list/get/create/rotate/delete api-key, so you can manage your own personal API keys from the CLI and not only service account keys. The server endpoints were added in kosli-dev/server#7733. --personal can't be combined with --service-account, one of the two is required, and --org isn't needed for personal keys.

kosli list api-keys --personal --api-token $TOKEN
kosli create api-key --personal -d "CI"
kosli rotate api-key KEY-ID --personal
kosli delete api-key KEY-ID --personal

Related to #925

Checklist

• Docs are autogenerated from CLI help — make sure the help text reflects your changes
• Helm chart (charts/k8s-reporter/) updated, if needed. Note: these changes live in a separate PR (not needed)
• Terraform provider and related changes (terraform-provider-kosli, terraform-aws-evidence-reporter, terraform-aws-kosli-reporter) updated, if needed (not needed)

[claude]

Claude finished @mbevc1's task in 1m 41s —— View job

---

PR review: --personal for kosli … api-key

• Static checks
• Read the diff and the tests
• Post the review

Static checks: go build ./..., go vet and go mod tidy all pass, and go.mod/go.sum didn't change.

Verdict: Looks good to merge. I found no bugs. The earlier --personal=false problem is fixed in bd93ed8. apiKeyOwner.validate() now checks the flag's actual value instead of whether it was passed. All five commands share the check, and TestPersonalFalseNeedsServiceAccount covers it on every one of them. Thanks also for correcting me about --service-account "": the empty-flag guard does reject it.

What's done well

• apiKeyOwner keeps things in one place (cmd/kosli/apiKey.go:17-48). Flag setup, owner/org checks and URL building used to be repeated in five commands. They now live in one type, and each command's run() gets simpler (o.owner.url(keyID, "rotate")).
• Org isn't required for personal keys, and dry-run tests without --org prove it.
• The output says "personal" when it should. The delete confirmation prompt and the success message both name personal keys, and the tests check the exact text.
• The help text explains what's surprising. It covers keys created with another API key: they expire no later than that key, and they're revoked or deleted along with it. It also points to the profile page if you need a key that lasts longer.
• Tests cover both paths: dry-run URL checks plus httpfake checks of real responses for list, get, create, rotate (several keys) and delete. The empty-flag audit spec is updated too.

Small, optional points

1. Empty key ID. This was already true before the PR, and --personal makes it a bit more serious. url.JoinPath drops empty parts, so kosli delete api-key "" --personal -y sends DELETE /api/v2/user/api-keys, the collection URL, and get api-key "" sends a list request. The server probably returns 405 or 404, but a quick check in the commands that take key IDs would be safer. For example, in deleteApiKey.go/rotateApiKey.go/getApiKey.go:

   for _, id := range args {
       if strings.TrimSpace(id) == "" {
           return fmt.Errorf("API key ID must not be empty")
       }
   }

   I couldn't run the binary here to confirm the request it actually sends. I'm going by how JoinPath behaves. Fix this →
2. The docs no longer mark --service-account as required. Because RequireFlags(cmd, "service-account") was removed, the generated docs drop the required marker. The flag descriptions now say "Either this or --personal is required", which covers it. I'm only mentioning it so the docs diff isn't a surprise.
3. A personal-key confirmation test with --yes. Optional: one more test case where --personal --yes skips the prompt. The service-account path already has one.