L7 Intention That Behaves Like a Blanket Allow

L7 permissions are only evaluated when Consul knows the destination speaks an L7 protocol. That is declared by a service-defaults config entry, and the default protocol is tcp. Because no config entries exist, payments is treated as TCP, so the permission list is never compiled into Envoy's HTTP filters and the intention degrades to a plain L4 allow. The security team's wildcard deny is defeated by an allow intention that was supposed to be path-scoped.

Steps:

1. Write the config entry:

Kind = "service-defaults"
Name = "payments"
Protocol = "http"

1. Regenerate the sidecars so Envoy receives HTTP listeners and filters. Config entries propagate over xDS, but a protocol change changes the shape of the proxy's config, so plan a rolling restart of the payments sidecars and, in practice, of the calling web sidecars too.
2. Re-test with a POST /v1/refunds - expect a 403 from the downstream sidecar, not a connection error. A 403 confirms the filter is doing the work; a connection reset usually means mTLS or intention matching failed earlier.

Note this also means L7 features are unusable with the built-in proxy, which is L4 only; Envoy sidecars are required.

Intentions are matched most-specific-first, and the wildcard * -> * deny sits at the bottom of that ordering. Adding an exact-source, exact-destination allow for reporting -> payments will therefore win over the wildcard deny without touching any existing rule - no need to modify the web intention or to relax the wildcard.

Order of operations:

1. Confirm reporting actually runs a sidecar. Intentions match on the source's mTLS identity, i.e. the service name in its certificate. A reporting process without a sidecar has no identity and can never match; it will simply be denied, and the logs will look like a rule problem rather than a topology problem.
2. Create the intention with the L7 permissions for GET /v1/reports/* on destination payments. The http protocol is already set on payments from the earlier fix, so the permission list will be enforced rather than ignored - verify this assumption rather than trusting it, since a missing protocol silently converts the rule to a blanket allow.
3. Verify with consul intention check -src reporting -dst payments that it reports the new intention as the match, and confirm the web rule still wins for web.
4. Deploy and test both the intended path (200 on /v1/reports/x) and an adjacent path (/v1/refunds should still 403 for reporting).

No restart of the payments sidecar is needed: intentions are pushed to proxies dynamically, which is the point of keeping them out of static config.

Intentions are enforced by the destination sidecar on the source identity presented in the mTLS certificate. A process without a sidecar has no certificate issued by the mesh CA, so it has no identity that an intention can match - there is no source name to write in a rule.

Options:

• Put it in the mesh (recommended). Register a sidecar for the batch job, even if it only makes outbound calls. The job then presents an identity you can name in an intention, and you get mTLS plus the same L7 filtering as everyone else.
• Route through an ingress gateway. The caller connects to a gateway, and the gateway's service identity is what reaches payments. The intention is then written against the gateway's service name, not the job's, so the rule is necessarily broader than the job itself and must be reviewed as such. Appropriate when many external callers share a controlled entry point.
• Bypass the mesh to the pod/VM directly. This works only while the target's port is reachable and is exactly what the mesh migration was meant to close; it also bypasses the intention entirely, so a path-scoped rule protects nothing. Treat any such residual path as a finding, not a design.

The judgement point: an intention cannot be granted to something that has no mesh identity, so the answer is always a topology change (add a sidecar or a gateway), never a new rule.