Repository navigation
Bind the notebook sample's container to loopback and restrict its database origins - #2382
Merged
Merged
Conversation
…abase origins Bind the published port to 127.0.0.1 so the Jupyter proxy is the only path to Graph Explorer, as deploy-to-sagemaker.md already describes. Jupyter connects from inside the instance, so the documented path is unaffected. Set PROXY_SERVER_ALLOWED_DB_ORIGINS in both docker run calls so the proxy only signs requests for the configured cluster, following the security.md guidance for hosts with AWS credentials. The value comes from a new ALLOWED_DB_ORIGINS variable that defaults to NEPTUNE_URI, the cluster's bare origin, and the lifecycle log prints it. Explain in the SageMaker guide how to add another database's origin, since network routing alone no longer reaches it. Add the new variable to the test that mirrors the script's docker run variables.
kmcginnes
force-pushed
the
sagemaker-sample-loopback-and-origins
branch
from
October 7, 2026 21:23
6cf0889 to
d1e1392
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Bring the SageMaker sample lifecycle script in line with our own documentation for how the notebook deployment is reached and which databases its proxy server contacts.
docs/guides/deploy-to-sagemaker.mddescribes the Jupyter proxy as the only access path to the container. The script now publishes the container port on loopback only.docs/references/security.mdrecommends settingPROXY_SERVER_ALLOWED_DB_ORIGINSwherever the host has AWS credentials, such as a notebook instance role. The script now sets it to the configured cluster.NEPTUNE_URI="https://${GRAPH_NOTEBOOK_HOST}:${GRAPH_NOTEBOOK_PORT}" +ALLOWED_DB_ORIGINS="${NEPTUNE_URI}" start_graph_explorer_with_cw_logs() # and _with_default_logs() - docker run -d -p 9250:9250 + docker run -d -p 127.0.0.1:9250:9250 --env GRAPH_CONNECTION_URL=${NEPTUNE_URI} + --env "PROXY_SERVER_ALLOWED_DB_ORIGINS=${ALLOWED_DB_ORIGINS}"ALLOWED_DB_ORIGINSis a variable rather than an inline value so deployers have one place to add an origin, which the guide's Network Requirements section now explains. The lifecycle log prints the effective value next to the Neptune URI.Evidence
Before: The sample script didn't match the guide's Security model or the allowlist guidance in
security.md.After:
pnpm test packages/graph-explorer-proxy-server/src/process-environmentpasses, 62/62. The test that mirrors the script'sdocker runvariables picks up the new variable.Verified live: A notebook instance booted through this script, with only its two documented placeholders filled. The container listens on
127.0.0.1:9250and/statusreturns 200 over loopback. Through the Jupyter proxy the UI loads, schema sync completes, and a Gremlin query returns results that render, with every captured proxy request returning 200. A request naming a database origin outside the allowlist returns 403.Merge Danger
Door: two-way
Each change is one line per
docker runcall and reverts cleanly.Impact: deployment
Existing notebooks keep their current lifecycle configuration until it is updated, so this reaches a deployment only when its lifecycle configuration is replaced and the instance restarts. A Connection to a database other than the configured cluster then needs its origin added to
ALLOWED_DB_ORIGINS, which is worth a release note.--env HOST=127.0.0.1is left alone; it only feeds the certificate name and the startup banner.Related