Skip to content

feat(chart): make NebariApp gateway explicit (public) for frontend and webapi - #13

Closed
viniciusdc wants to merge 1 commit into
mainfrom
feat/explicit-public-gateway-nebariapp
Closed

feat(chart): make NebariApp gateway explicit (public) for frontend and webapi#13
viniciusdc wants to merge 1 commit into
mainfrom
feat/explicit-public-gateway-nebariapp

Conversation

@viniciusdc

Copy link
Copy Markdown
Collaborator

Description

Adds an explicit gateway: public field to both NebariApp CRs defined in the nebariapp.yaml chart template, instead of relying on the kubebuilder default value.

Why

The NebariApp spec has gateway as an optional field with a +kubebuilder:default=public marker. While the default is public, making it explicit:

  1. Makes the intent clear in the rendered manifest — reviewers don't need to look up the CRD defaults to understand which gateway is used.
  2. Prevents surprises if the default ever changes in a future operator version.
  3. Adds an explanatory comment documenting the oauth2-proxy architecture and the planned migration path.

Architecture note

Frontend NebariApp (/oauth2/* + /* → oauth2-proxy sidecar):

  • auth.enabled: false / enforceAtGateway: false — the Gateway passes traffic straight through to the pod.
  • The oauth2-proxy sidecar in the frontend pod intercepts every request and enforces Keycloak login before proxying to the nginx static server.

Webapi NebariApp (/api/* → Go webapi):

  • auth.enabled: false / enforceAtGateway: false — no SecurityPolicy created.
  • The webapi validates Bearer tokens in-process via its JWT validator.

Future migration path

Once nebari-operator#61 is resolved, the oauth2-proxy sidecar can be made optional. At that point this chart can switch the frontend NebariApp to auth.enabled: true, enforceAtGateway: true, moving OIDC enforcement to the Envoy Gateway level natively.

Changes

  • charts/nebari-landing/templates/nebariapp.yaml: add gateway: public + comments to both NebariApp resources

Testing

  • Render the chart with helm template and confirm both NebariApp resources include gateway: public:
    helm template nebari-landing charts/nebari-landing     --set nebariApp.enabled=true     --set httpRoute.hostname=nebari.example.com     | grep -A2 'kind: NebariApp'

Both NebariApp resources (frontend + webapi) now explicitly set
gateway: public instead of relying on the kubebuilder default.

The frontend uses oauth2-proxy as a sidecar to enforce auth before
requests reach the React SPA — no SecurityPolicy is needed at the
gateway level (enforceAtGateway: false, auth.enabled: false).

The webapi validates JWTs in-process; same reasoning applies.

Future: once nebari-operator#61 is resolved, the oauth2-proxy sidecar
can be made optional and auth enforcement moved to the gateway level
(EnforceAtGateway: true) via native Envoy Gateway OIDC.
@github-actions

Copy link
Copy Markdown
Contributor

Docker images built for this PR

Branch tag: feat-explicit-public-gateway-nebariapp

Component Image Platforms
webapi quay.io/nebari/nebari-webapi:feat-explicit-public-gateway-nebariapp linux/amd64 · linux/arm64
frontend quay.io/nebari/nebari-landing:feat-explicit-public-gateway-nebariapp linux/amd64 · linux/arm64

To deploy this PR locally:

helm upgrade --install nebari-landing charts/nebari-landing \
  --namespace nebari-system \
  --set webapi.image.tag=feat-explicit-public-gateway-nebariapp \
  --set frontend.image.tag=feat-explicit-public-gateway-nebariapp

@viniciusdc viniciusdc closed this Mar 11, 2026
@viniciusdc
viniciusdc deleted the feat/explicit-public-gateway-nebariapp branch March 11, 2026 23:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant