How To Utilize Network Policy with Ambient?

[jsievenpiper]

👋🏾 Hi there!

I am trying to move workloads to ambient in a zero-trust cluster, but for the life of me I can't figure out what Network Policy should look like for this -- with the previous sidecar model network policy just worked, and I think that's supposed to be the case here.

ztunnel does seem to be picking up traffic:

2024-06-14T19:17:41.958364Z    error    access    connection complete    src.addr=10.42.154.116:41090 src.workload=kiali-555c8bc6df-kfsdm src.namespace=istio-kiali dst.addr=10.43.0.1:443 direction="outbound" bytes_sent=2641 bytes_recv=63321 duration="3137ms" error="client disconnected before all data was written" 
2024-06-14T19:17:47.326707Z    error    access    connection complete    src.addr=10.42.116.234:52050 src.workload=grafana-agent-shard-2-0 src.namespace=grafana-agent dst.addr=10.42.154.116:9090 dst.service=kiali.istio-kiali.svc.cluster.local dst.workload=kiali-555c8bc6df-kfsdm dst.namespace=istio-kiali direction="inbound" bytes_sent=0 bytes_recv=0 duration="0ms" error="connection closed due to policy rejection"

10.43.0.1:443 is the cluster's K8S API server.

These requests are initiated from a browser, so it also seems like the net policy from the ingress gateway (defined using the K8S Gateway API) is working out okay.

It's probably worth noting that ztunnel is running in the same namespace as istiod which has network policy installed, so I'm not sure what policy should look like for ztunnel itself. Even though I haven't explicitly allowed any traffic through it, the fact that it's picking up requests and configuration has made me aware I'm in way over my head here on where network policy is to be applied. 🙃

I saw there was some testing done (#49301), but couldn't find any documentation on how or what was done. If I could get some help here, I'd be more than happy to document this for the Istio docs for future users.

Thanks!

[howardjohn]

So "connection closed due to policy rejection" is from an AuthorizationPolicy denying things, not a network policy.

There are two connections here, one to the API server. This lasted 3s and exchanged a lot of data, but the client (kiali) disconnected before all the data was read. This doesn't seem like a policy error, just kiali not fully reading the body.

The second connection seems unrelated to the first, but is denied by an authz policy.

Neither of these seem to be networkpolicy issues.

Happy to help iterate on this more quickly on slack if you are on it btw, in #ambient or DM

[howardjohn]

For future readers, on slack we found:

• Kiali error was an excessive logging; fixed in Hide error logs when peer shut's down for us ztunnel#1144
• Grafana-agent to kiali was due to STRICT mode without grafana-agent in the mesh. Fixed by adding it into the mesh https://blog.howardjohn.info/posts/securing-prometheus/
• Remaining case (not either of the logs in the original post, but other issues) were around port-level NetPol. Istio tunnels the traffic over port 15008, so the netpol applies on that port rather than the original port.