feat: issue token for each kubeconfig on export

[merll]

This PR changes the Kubeconfig generation, creating a token on-demand with a set expiration time.

CA is now inserted for validation if available.

[Copilot]

Copilot review overview

🟡 Changes recommended

Incorrect settings access, token audiences, and kubeconfig structure currently produce unusable exports.

Review effort: Balanced
Findings: 1 · 1 · 1

Open (3)

• Incorrect cluster settings destructuring produces invalid download · New
• TokenRequest audience incorrectly set to user subject · New
• Missing tests for token request and generated kubeconfig · New

What changed in this PR

Introduces short-lived, TokenRequest-backed kubeconfig exports and reusable Kubernetes API helpers.

Changes:

• Adds configurable service account token generation.
• Generates and serializes kubeconfigs directly.
• Extracts shared Kubernetes client operations from CloudTty.

File	Description
src/​validators.ts	Adds kubeconfig token settings.
src/​tty.ts	Uses shared Kubernetes helpers.
src/​tty.test.ts	Removes relocated helper tests.
src/​otomi-stack.ts	Integrates per-export token generation.
src/​kubecfg.ts	Implements token and kubeconfig generation.
src/​kubeapi.ts	Adds reusable Kubernetes operations.
src/​kubeapi.test.ts	Tests shared operations.
src/​api/​v1/​kubecfg/​{teamId}.ts	Serializes generated configuration.
src/​api.authz.test.ts	Updates endpoint mocks.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟡 Changes recommended

Team validation, API-server validation, token audience portability, and secure CA handling must be addressed.

Review effort: Balanced
Findings: 1

Open (1)

• Use default API server audiences for exported tokens · New

Resolved since last review (3)

• Incorrect cluster settings destructuring produces invalid download
• TokenRequest audience incorrectly set to user subject
• Missing tests for token request and generated kubeconfig

Previously missed (1)

In code that hasn't changed since last review

Restore team existence validation before kubeconfig export

src/​otomi-stack.ts:2329

The previous implementation validated teamId with getAplTeam before exporting. Without that check, a platform admin can request an arbitrary/nonexistent team ID and still receive a valid team-admin kubeconfig, contrary to this endpoint's team-scoped contract and documented 404 response. Restore the existence check before selecting the namespace.

This issue also appears on line 2339 of the same file.

[Copilot]

Copilot review overview

🟡 Changes recommended

Team targeting, configuration validation, token audience handling, and TLS fallback have unresolved correctness and security issues.

Review effort: Balanced
Findings: 1 · 2

Open (3)

• Fail generation when CA certificate is unavailable · New
• Restore team existence check before issuing kubeconfig token · New
• Use default API server audiences for exported tokens

[Copilot]

Copilot review overview

🔵 Needs a closer look

Token audience compatibility, missing API-server validation, and incorrect platform-admin context targeting must be addressed.

Review effort: Balanced
Findings: None

Resolved since last review (3)

• Fail generation when CA certificate is unavailable
• Restore team existence check before issuing kubeconfig token
• Use default API server audiences for exported tokens

Previously missed (2)

In code that hasn't changed since last review

Preserve requested team namespace in exported kubeconfig

src/​otomi-stack.ts:2335

A platform admin requesting /v1/kubecfg/{teamId} now always receives a config whose current namespace is team-admin, even though the endpoint validates the requested team and names the download for that team; previously it exported team-${teamId}. This makes the exported context target a different namespace than requested. Keep the requested team as the context namespace, and if the admin token must come from team-admin, pass the service-account namespace separately.

Restore validation for missing cluster API server

src/​otomi-stack.ts:2346

This removes the previous runtime check for the optional cluster.apiServer setting. Because getSettings is cast to Record<string, any>, a missing value bypasses the string type and produces a downloaded kubeconfig with no server after a token has already been issued. Restore the validation before constructing the generator.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Missing API-server validation can issue a token and return an unusable kubeconfig.

Review effort: Balanced
Findings: None

Resolved since last review (1)

• Use default API server audiences for exported tokens

Previously missed (2)

In code that hasn't changed since last review

Validate cluster.apiServer before generating kubeconfig

src/​otomi-stack.ts:2348

The previous implementation rejected a missing cluster.apiServer, but this now passes undefined into the generator. Because apiServer is optional in src/openapi/cluster.yaml, this can issue a live token and then return a kubeconfig with no server URL. Restore the validation before constructing the generator.

Identify kube-root-ca.crt as a ConfigMap, not a Secret

src/​kubecfg.ts:42

This diagnostic calls kube-root-ca.crt a Secret, but the value is read from a ConfigMap. Using the correct resource kind avoids misleading operators investigating the failure.

This issue also appears on line 47 of the same file.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Invalid token-expiration configuration can pass startup validation and break every kubeconfig export.

Review effort: Balanced
Findings: None

Previously missed (2)

In code that hasn't changed since last review

Validate TokenRequest expiration within Kubernetes bounds

src/​validators.ts:229

Validate this value as an integer in Kubernetes' accepted TokenRequest range (600 through 2^32 seconds). num also accepts fractional, smaller, and larger values, so a syntactically valid environment setting can make every kubeconfig export fail at the API server instead of failing fast during startup.

Correct diagnostic to identify kube-root-ca.crt as a ConfigMap

src/​kubecfg.ts:42

This diagnostic identifies kube-root-ca.crt as a Secret, but the code reads it as a ConfigMap. Naming the actual resource avoids sending operators to inspect the wrong object when CA lookup fails.

[Copilot]

Copilot review overview

🟡 Changes recommended

Multi-team kubeconfig exports can resolve contexts to the wrong ServiceAccount token because user names collide.

Review effort: Balanced
Findings: 1

Open (1)

• Avoid kubeconfig name collisions across teams and clusters · New

Previously missed (1)

In code that hasn't changed since last review

Identify kube-root-ca.crt as a ConfigMap, not a Secret

src/​kubecfg.ts:42

This diagnostic identifies kube-root-ca.crt as a Secret, but the code reads it as a ConfigMap. Referencing the correct resource kind avoids misleading operators investigating missing CA data.

This issue also appears on line 47 of the same file.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Expiration values accepted at startup can be rejected by Kubernetes and break every kubeconfig export.

Review effort: Balanced
Findings: None

Resolved since last review (1)

• Avoid kubeconfig name collisions across teams and clusters

Previously missed (1)

In code that hasn't changed since last review

Validate kubeconfig expiration as integer of at least 600 seconds

src/​validators.ts:229

Kubernetes rejects TokenRequest lifetimes below 600 seconds and requires this field to be an integer, but num accepts values such as 0, 300, or 600.5. Those configurations pass startup and then make every kubeconfig export fail at the API server. Validate KUBECONFIG_EXPIRATION_SECONDS as an integer of at least 600 during environment parsing.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Credential issuance and deployment-level service-account/RBAC assumptions require final human validation.

Review effort: Balanced
Findings: None

[Copilot]

Copilot review overview

🟡 Changes recommended

Expiration settings accepted by startup validation can be rejected by the Kubernetes TokenRequest API.

Review effort: Balanced
Findings: 1

Open (1)

• Validate expiration seconds as an integer of at least 600 · New

[CasLubbers]

token on kubecfg has an expiration date ✅