[braghettos]

Closes #36.

Summary

POST /serviceaccount/login returned the issued identity's full kubeconfig in data, including client-key-data, a private key. The natural first debugging step, printing the response, wrote that key into a terminal or CI log, as reported in #36.

• Response: now carries only accessToken, user and groups.
• Secret: the generator still mints the identity and persists the <username>-clientconfig Secret. plumbing endpoints, snowplow and bff read the kubeconfig from that Secret, so the Secret is untouched.
• Human strategies (basic, ldap, oauth, oidc): unchanged. They still return data, and the frontend uses it, e.g. /basic/login?d.

Compatibility

Response-contract change: the next release should be a minor bump. Before shipping, the endpoint's consumers were checked:

• core-provider: it grepped 56 repos with positive controls. It found four distinct clients of this endpoint, and every one decodes accessToken only:
  • core-provider/internal/tools/authn/authn.go:116
  • composition-dynamic-controller/internal/authn/authn.go
  • rest-dynamic-controller/internal/tools/authn/authn.go:111
  • snowplow/internal/authn/authn.go:135
• Teams: oasgen-provider (rest-dynamic-controller), core-provider, snowplow and provider-runtime each confirmed independently.
• A fifth consumer, outside the code grep: acmp's scheduled-export CronJob (saas krateo-scheduled-export 0.5.0) pipes the body into jq .accessToken. It's also unaffected.

Docs

• behavior.md and api.md: the response contract now notes that the serviceaccount login omits data, and that client-key-data is a private key.
• The serviceaccount-mapping example: the README describes the new response.
• log.md: new entry.

Test plan

• New TestHandlerOmitsKubeconfigFromResponse drives the real handler against a fake apiserver (TokenReview + mapping list). It asserts:
  • there is no data and no client-key-data in the body;
  • accessToken, user and groups are present;
  • the clientconfig generator was still called.
• Negative control: the test fails against the previous handler.
• CI.
• Optional: the The /serviceaccount/login response contains a client private key, and nothing says so #36 reporter (aruba-provider-kog) offered their authn 0.27.3 rig to verify the change end to end.

Merge order

This PR conflicts trivially with #40, which adds CertNotAfter to the same encode.Success call. Whichever merges second needs a one-line rebase.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TLFnUe4HXFphxQNAfqFawZ