nebari-dev / nebari-dev/llm-serving-pack
Align buildExternalSecurityPolicy and buildInternalSecurityPolicy shape
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 3
- Forks
- 3
- Avg merge
- 16h 31m
- Merged PRs (30d)
- 11
Description
Follow-up from #47.
auth.go now has two sibling builders with divergent shape:
buildExternalSecurityPolicyassembles the whole object inline inside theObject:literal.buildInternalSecurityPolicysplitsspecinto a local first so it can conditionally append theauthorizationblock.
This is fine today but worth revisiting the next time the external policy needs a conditional field - e.g., the sanitize: true / forwardClientIDHeader fields already TODO'd for when we bump the Envoy Gateway minimum to v1.7+ (inline comment in buildExternalSecurityPolicy). At that point, factor both to the same local-spec shape so they stay parallel.
No action right now; link from whatever PR does the EG v1.7 bump.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
When the Envoy Gateway v1.7 bump is underway, start in auth.go and inspect buildExternalSecurityPolicy, buildInternalSecurityPolicy, and the inline TODO about sanitize and forwardClientIDHeader. The work is done when both builders use the same local-spec shape while preserving the conditional authorization block.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- authentication
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100