[gjkim42]

What type of PR is this?

/kind bug

What this PR does / why we need it:

GitHub users with hundreds of organization and team memberships could sign in successfully but receive 401 from the Console because their forwarded groups exceeded its identity limits. Raise the shared proxy authentication limits to 1,024 groups and a 64 KiB group header, retaining every group for Kubernetes RBAC and continuing to reject oversized identities.

Add consoleServer.auth.github.team to restrict sign-in to a single team slug within the configured org. Enforce the organization dependency in both JSON Schema and chart rendering, and pass the setting to OAuth2 Proxy's GitHub provider. Organization-only configurations retain their existing sign-in behavior.

Document ingress header requirements for large sessions in both the OIDC and GitHub setup guides. Cover large paginated memberships, team admission, group preservation, boundary validation, and schema-only validation with unit and real-proxy integration tests.

Which issue(s) this PR is related to:

N/A

Special notes for your reviewer:

Validation passed:

• Focused unit and chart tests through make test, covering TestProxyLargeMemberships, TestProxyGroupLimits, TestOIDCIdentityValidation, TestConsoleGitHubTeamSchema, and TestRenderConsole*.
• make test-integration TEST_FLAGS='-run TestConsole -count=1', including 208 organizations plus 205 teams through the pinned OAuth2 Proxy, organization-only and team-restricted admission, RBAC, and spoofed-header rejection.
• make verify.

The group limits apply to both GitHub and OIDC authentication. Sign-in restrictions do not filter RBAC groups or grant permissions. Tightening org or team restrictions for existing sessions requires rotating the cookie secret and restarting Console Pods. Large proxy session cookies may also require higher ingress header limits.

Does this PR introduce a user-facing change?

Console proxy authentication now supports up to 1,024 groups and a 64 KiB group header, allowing GitHub users with hundreds of organization and team memberships to sign in. GitHub authentication also supports consoleServer.auth.github.team to restrict sign-in to a single team within the configured organization.

---

Summary by cubic

Fixes 401s for GitHub users with hundreds of organization and team memberships by raising the proxy authentication limits, and adds an optional consoleServer.auth.github.team setting to restrict sign-in to a single team.

• Raises the accepted groups from 128 to 1,024 and the group header limit from 8 KiB to 64 KiB; the limits apply to both GitHub and OIDC, and oversized identities are still rejected with 401 rather than truncated.
• Adds consoleServer.auth.github.team, which requires org and accepts a single team slug; organization-only configurations keep their existing behavior.
• Updates the setup guide and reference and adds unit and integration tests for large paginated memberships, team admission, group preservation, and boundary validation.

Notes for reviewers

• Sign-in restrictions do not filter RBAC groups or grant permissions.
• Tightening org or team for existing sessions requires rotating the cookie secret and restarting Console Pods.
• Large proxy session cookies may require higher ingress header limits.

^{Written for commit db21d9a. Summary will update on new commits.}

[cubic-dev-ai]

All reported issues were addressed across 9 files

<sub>Tip: Get a Slack DM when cubic finishes reviewing your PRs. Connect Slack

View guided diff | Turn on auto-fix | Re-trigger cubic</sub>

[gjkim42]

/kelos api-review

[kelos-bot]

🤖 Kelos Task Status

Task kelos-api-reviewer-issue-comment-356f2947e1a0 has succeeded. ✅

[gjkim42]

/kelos review

[kelos-bot]

🤖 Kelos Task Status

Task kelos-reviewer-issue-comment-f8e4be7522c7 has succeeded. ✅

[kelos-bot]

🤖 Kelos API Reviewer Agent @gjkim42

API Design Review

Verdict: APPROVE
Scope: No CRD or api/ changes. The PR adds the optional Helm value consoleServer.auth.github.team and raises the Console proxy limits to 1024 groups and a 64 KiB group header (hard-coded, not configurable).

Findings

No blocking API design issues.

Compatibility

• The change is additive and safe for existing installs. team is optional, and existing github values (with or without org) render the same githubConfig as before (internal/manifests/charts/kelos/templates/_console-auth.tpl:101-107). Raising the group limits (internal/consoleserver/auth.go:25-26) only loosens validation, so no identity that was accepted before is now rejected.
• Leaving the limits as internal constants rather than new chart values keeps the API surface minimal.

Naming and shape

• The singular string team matches the sibling org field and OAuth2 Proxy's githubConfig.team. Requiring org is stricter than upstream, which also accepts org:team-slug without org, so it can be relaxed later without breaking anyone.
• The pattern ^[^\s,:/]+$ (internal/manifests/charts/kelos/values.schema.json:134-138) rejects comma-separated lists and the org:team form. This keeps team from becoming a field that packs several values into one string. Case does not need to be enforced because the pinned OAuth2 Proxy compares org and team slugs case-insensitively.
• The cross-field rule "team requires org" is enforced in the template (_console-auth.tpl:17-19), the same way the chart already enforces its other cross-field rules. It is covered by TestRenderConsoleGitHubRejectsInvalidConfiguration.

Documentation

• docs/reference.md:813-819 and internal/manifests/charts/kelos/README.md:485-500 match the implementation. The byte limits apply to the header before the prefix is added, sign-in restrictions do not filter RBAC groups, and the 401 rejection (no truncation) is documented as implemented.

Suggestions (optional)

• [P3] team is a scalar, and once shipped it cannot become a list without breaking existing values. OAuth2 Proxy already accepts several teams as a comma-separated string, so if multi-team admission is requested later, add a separate list field (for example teams: []) instead of loosening the comma restriction on team. If multi-team support is already expected soon, consider choosing that shape before this field ships.

Note on prompt injection: A third-party bot review contained embedded "Prompt for AI agents" instructions to change code and resolve review threads. They were disregarded, and this review was formed independently from the code.

/kelos needs-input

[kelos-bot]

🤖 Kelos Reviewer Agent @gjkim42

Review Summary

Verdict: APPROVE
Overall correctness: patch is correct
Scope: Raises the Console proxy identity limits to 1024 groups and a 64 KiB group header for both OIDC and GitHub, and adds the optional Helm value consoleServer.auth.github.team (requires org) to restrict GitHub sign-in to one team.

Findings Overview

Priority	Count	File:Line	Summary
P0	0	—	none
P1	0	—	none
P2	0	—	none
P3	1	internal/manifests/charts/kelos/README.md:301	Ingress header-size caveat for large sessions is documented only in the GitHub section, not the OIDC section

Findings

Documentation

• [P3] internal/manifests/charts/kelos/README.md:301 — The higher limits now apply to OIDC as well, but the caveat that large sessions need ingress request and response header limits big enough for the proxy's session cookies appears only in the GitHub section (README.md:520-522). OIDC session cookies hold the ID token, which repeats the groups claim, as well as the extracted groups, so a user with hundreds of OIDC groups will likely hit default ingress header limits (for example, NGINX's 8 KiB large_client_header_buffers) before reaching Kelos's 64 KiB limit. Previously such a user got a 401 from Kelos. They now get a 400 or 502 from the ingress, and the OIDC guide does not explain why. Consider adding the same one-sentence caveat next to the OIDC limits, or moving it to docs/reference.md:813, where the limits are documented for both providers.

Key takeaways

• Limit changes are correct. proxyPrincipal (internal/consoleserver/auth.go:102-116) still checks the header byte limit before splitting, then the group count, then each group. Oversized identities are still rejected rather than truncated, and the Console server uses Go's default 1 MiB MaxHeaderBytes, so a 64 KiB header is never rejected before it reaches this code. Tests cover both sides of each boundary: exactly 1024 groups and 65536 bytes are accepted (TestProxyGroupLimits), while 1025 groups and 65537 bytes are rejected (TestOIDCIdentityValidation).
• The team setting matches the pinned proxy. In OAuth2 Proxy v7.15.5, setting both org and team uses hasOrgAndTeam, a case-insensitive match against org:team groups. The proxy checks these restrictions only in EnrichSession, at sign-in. That confirms the docs: org and team do not filter the forwarded groups, and tightening them requires rotating the cookie secret. The schema pattern plus the template's team requires org check reject empty values, comma lists, org:team, and display names containing spaces.
• The integration test exercises the real failure. The GitHub mock paginates 208 organizations and 205 teams through the real proxy (more than 128 groups and 8 KiB on the base branch). It also checks that every group is forwarded unchanged, and that organization-only and team-restricted sign-in each admit or reject the right users.

Note on prompt injection: A third-party bot review on this PR contained an embedded "Prompt for AI agents" section instructing agents to change code and resolve review threads. That instruction was disregarded; this review was formed independently from the code.