Repository navigation
a network policy update answers 204 with no body, as Sprites does (#26) - #27
Merged
Merged
Conversation
POST /v1/sprites/{id}/policy/network answered 200 with the stored rules.
The Sprites Go, JS, Python and Elixir SDKs all accept only 204 there, and
wisp answers 204, so fountain (managoat_sandbox on the Elixir SDK) failed
every networking_type: limited Environment on spritzer. The policy is still
stored and returned by GET, and the README says it is not enforced.
Closes #26
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
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.
Closes #26.
POST /v1/sprites/{id}/policy/networknow answers204with no body. It answered200with the stored rules.Which side was off
spritzer. The real API answers the policy update with 204, and every official SDK rejects any other status:
policy.go:75:if resp.StatusCode != http.StatusNoContentis an error@fly/sprites0.2.3dist/policy.js:34:if (response.status !== 204) throwsprites-py0.7.1sprites/policy.py:100:if response.status_code != 204raisessprites0.2.2 (superfly/sprites-ex)lib/sprites/policy.ex,update_by_name: only{:ok, %{status: 204}}is:ok, a 200 becomes{:error, {:api_error, 200, body}}fountain v0.21.0 uses managoat_sandbox 0.5.0, whose Sprites adapter (
lib/managoat/sandbox/sprites.ex,apply_network_policy) callsSprites.update_network_policyfrom that Elixir SDK, so its{:invalid, {:http, 200, ...}}is the SDK's rejection, normalised. wisp answers 204 (internal/server/egress_test.go:104). The docs page at sprites.dev/api/sprites/policies lists a generic "200 Success" for the POST with no response fields; the SDKs are what the service is tested against, and they agree on 204.GET on the same path is unchanged:
200 {"rules": [...]}, as documented.Enforcement
Not enforced, in either mode, and not changed here. The README's container-mode section now says so explicitly for network policy, and
docs/container-mode.mdalready did.Verified
fountain-ops main on k3d (fountain v0.21.0, dataPlane=spritzer, container mode,
acpFixtureUserId), with this branch's image imported asspritzerImage:networking_type: limitedwithallowed_hosts: ["registry.npmjs.org"]:stage network failed {:invalid, {:http, 200, %{"rules" => [...]}}}, conversationfailednetwork done, the fixture turn endsend_turn, and the artifact reads back from the sprite pod; spritzer's GET returns the allow ruleallowed_hosts: []:network done, turnend_turn, GET returns[{"domain":"*","action":"deny"}]chant's wire-compatible fake has the same 200 reply: INTENTIUS/chant#2719.