read me updates and hardening fixes - #3898
Merged
Merged
Conversation
Contributor
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThis PR aligns CI infrastructure by pinning the Postgres container to a fixed IPv4 address in docker-compose and updating harden-runner egress allow-lists across test jobs to permit this pinned IP (and Weaviate endpoints for API tests). It also publishes two new release changelogs: Enterprise v1.4.5 covering identity lifecycle and MCP authentication changes, and Helm v2.1.20 documenting a new ChangesCI Infrastructure Network Pinning
Release Documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
|
akshaydeo
marked this pull request as ready for review
May 29, 2026 18:44
Contributor
Author
Merge activity
|
Contributor
Confidence Score: 5/5All changes are safe to merge; the CI fixes are self-contained and the docs additions are well-formed. The docker-compose change correctly extends an already-working static-IP pattern to Postgres; the bifrost_network ipam subnet (172.38.0.0/16) already covered all other services at .11–.14 so no new infrastructure is introduced. All three harden-runner jobs that talk to Postgres via the published port have been updated. The changelog files are complete and both are wired into docs.json. No logic, schema, or Go code is touched. No files require special attention. Important Files Changed
Reviews (1): Last reviewed commit: "read me updates and hardening fixes" | Re-trigger Greptile |
akhsaul
pushed a commit
to akhsaul/bifrost
that referenced
this pull request
Aug 27, 2026
## Summary Fixes CI failures caused by `harden-runner`'s egress-policy blocking Postgres connections in the release pipeline. Because `harden-runner` filters on the post-NAT destination IP, host processes dialing `127.0.0.1:5432` are actually reaching Postgres at its Docker bridge IP after DNAT. The Postgres container now has a pinned bridge IP (`172.38.0.11`) and that IP:port is explicitly added to the `allowed-endpoints` list for every release-pipeline job that connects to Postgres (`test-migrations`, `test-bifrost-http`, `test-api-integrations`). This PR also adds the `ent-v1.4.5` and `helm-v2.1.20` changelogs. ## Changes - Assigned a static IPv4 address (`172.38.0.11`) to the Postgres container in `docker-compose.yml` so the post-NAT bridge IP is deterministic and can be allowlisted. - Added `172.38.0.11:5432` to the `harden-runner` `allowed-endpoints` in the `test-migrations`, `test-bifrost-http`, and `test-api-integrations` jobs in `release-pipeline.yml`. Added inline comments explaining the DNAT behaviour and the requirement to keep the pinned IPs in sync. - Added `172.38.0.12:8080` and `172.38.0.12:8301` (Weaviate's pinned bridge IP) to the `test-api-integrations` job, which starts all Compose services and waits for Weaviate to become healthy. - Added `docs/changelogs/ent-v1.4.5.mdx` covering identity lifecycle, MCP per-user auth, governance UI sheets, and OSS base `transports/v1.5.6` additions. - Added `docs/changelogs/helm-v2.1.20.mdx` documenting the `authServerType` field addition to the Okta SCIM/SSO schema. - Registered both new changelog pages in `docs/docs.json`. ## Type of change - [ ] Bug fix - [ ] Feature - [ ] Refactor - [ ] Documentation - [x] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [x] Docs ## How to test Trigger the release pipeline and confirm the `test-migrations`, `test-bifrost-http`, and `test-api-integrations` jobs complete without `harden-runner` blocking egress to `172.38.0.11:5432`. Verify Weaviate health checks pass in `test-api-integrations` with the newly added `172.38.0.12` entries. ```sh # Verify Postgres container receives the pinned IP at runtime docker compose -f .github/workflows/configs/docker-compose.yml up -d postgres docker inspect <postgres_container> | grep '"IPAddress"' # Expected: 172.38.0.11 ``` ## Breaking changes - [ ] Yes - [x] No ## Related issues N/A ## Security considerations The pinned IPs are internal Docker bridge addresses scoped to the CI runner's network namespace. Allowlisting them in `harden-runner` does not expose any additional external endpoints; it only permits loopback-equivalent container-to-host traffic that was already implicitly occurring via the published port mapping. ## Checklist - [x] I read `docs/contributing/README.md` and followed the guidelines - [x] I added/updated tests where appropriate - [x] I updated documentation where needed - [x] I verified builds succeed (Go and UI) - [x] I verified the CI pipeline passes locally if applicable
occcat
pushed a commit
to occcat/bifrost
that referenced
this pull request
Sep 2, 2026
## Summary Fixes CI failures caused by `harden-runner`'s egress-policy blocking Postgres connections in the release pipeline. Because `harden-runner` filters on the post-NAT destination IP, host processes dialing `127.0.0.1:5432` are actually reaching Postgres at its Docker bridge IP after DNAT. The Postgres container now has a pinned bridge IP (`172.38.0.11`) and that IP:port is explicitly added to the `allowed-endpoints` list for every release-pipeline job that connects to Postgres (`test-migrations`, `test-bifrost-http`, `test-api-integrations`). This PR also adds the `ent-v1.4.5` and `helm-v2.1.20` changelogs. ## Changes - Assigned a static IPv4 address (`172.38.0.11`) to the Postgres container in `docker-compose.yml` so the post-NAT bridge IP is deterministic and can be allowlisted. - Added `172.38.0.11:5432` to the `harden-runner` `allowed-endpoints` in the `test-migrations`, `test-bifrost-http`, and `test-api-integrations` jobs in `release-pipeline.yml`. Added inline comments explaining the DNAT behaviour and the requirement to keep the pinned IPs in sync. - Added `172.38.0.12:8080` and `172.38.0.12:8301` (Weaviate's pinned bridge IP) to the `test-api-integrations` job, which starts all Compose services and waits for Weaviate to become healthy. - Added `docs/changelogs/ent-v1.4.5.mdx` covering identity lifecycle, MCP per-user auth, governance UI sheets, and OSS base `transports/v1.5.6` additions. - Added `docs/changelogs/helm-v2.1.20.mdx` documenting the `authServerType` field addition to the Okta SCIM/SSO schema. - Registered both new changelog pages in `docs/docs.json`. ## Type of change - [ ] Bug fix - [ ] Feature - [ ] Refactor - [ ] Documentation - [x] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [x] Docs ## How to test Trigger the release pipeline and confirm the `test-migrations`, `test-bifrost-http`, and `test-api-integrations` jobs complete without `harden-runner` blocking egress to `172.38.0.11:5432`. Verify Weaviate health checks pass in `test-api-integrations` with the newly added `172.38.0.12` entries. ```sh # Verify Postgres container receives the pinned IP at runtime docker compose -f .github/workflows/configs/docker-compose.yml up -d postgres docker inspect <postgres_container> | grep '"IPAddress"' # Expected: 172.38.0.11 ``` ## Breaking changes - [ ] Yes - [x] No ## Related issues N/A ## Security considerations The pinned IPs are internal Docker bridge addresses scoped to the CI runner's network namespace. Allowlisting them in `harden-runner` does not expose any additional external endpoints; it only permits loopback-equivalent container-to-host traffic that was already implicitly occurring via the published port mapping. ## Checklist - [x] I read `docs/contributing/README.md` and followed the guidelines - [x] I added/updated tests where appropriate - [x] I updated documentation where needed - [x] I verified builds succeed (Go and UI) - [x] I verified the CI pipeline passes locally if applicable
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
2 participants
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
Fixes CI failures caused by
harden-runner's egress-policy blocking Postgres connections in the release pipeline. Becauseharden-runnerfilters on the post-NAT destination IP, host processes dialing127.0.0.1:5432are actually reaching Postgres at its Docker bridge IP after DNAT. The Postgres container now has a pinned bridge IP (172.38.0.11) and that IP:port is explicitly added to theallowed-endpointslist for every release-pipeline job that connects to Postgres (test-migrations,test-bifrost-http,test-api-integrations). This PR also adds theent-v1.4.5andhelm-v2.1.20changelogs.Changes
172.38.0.11) to the Postgres container indocker-compose.ymlso the post-NAT bridge IP is deterministic and can be allowlisted.172.38.0.11:5432to theharden-runnerallowed-endpointsin thetest-migrations,test-bifrost-http, andtest-api-integrationsjobs inrelease-pipeline.yml. Added inline comments explaining the DNAT behaviour and the requirement to keep the pinned IPs in sync.172.38.0.12:8080and172.38.0.12:8301(Weaviate's pinned bridge IP) to thetest-api-integrationsjob, which starts all Compose services and waits for Weaviate to become healthy.docs/changelogs/ent-v1.4.5.mdxcovering identity lifecycle, MCP per-user auth, governance UI sheets, and OSS basetransports/v1.5.6additions.docs/changelogs/helm-v2.1.20.mdxdocumenting theauthServerTypefield addition to the Okta SCIM/SSO schema.docs/docs.json.Type of change
Affected areas
How to test
Trigger the release pipeline and confirm the
test-migrations,test-bifrost-http, andtest-api-integrationsjobs complete withoutharden-runnerblocking egress to172.38.0.11:5432. Verify Weaviate health checks pass intest-api-integrationswith the newly added172.38.0.12entries.Breaking changes
Related issues
N/A
Security considerations
The pinned IPs are internal Docker bridge addresses scoped to the CI runner's network namespace. Allowlisting them in
harden-runnerdoes not expose any additional external endpoints; it only permits loopback-equivalent container-to-host traffic that was already implicitly occurring via the published port mapping.Checklist
docs/contributing/README.mdand followed the guidelinesSummary by CodeRabbit
Documentation
Chores