api: allow_any_dynamic_dns mode in outbound traffic policy#3667
api: allow_any_dynamic_dns mode in outbound traffic policy#3667rudrakhp wants to merge 1 commit intoistio:masterfrom
Conversation
|
😊 Welcome @rudrakhp! This is either your first contribution to the Istio api repo, or it's been You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines Thanks for contributing! Courtesy of your friendly welcome wagon. |
istio-testing
added
the
size/XS
istio-testing
added
size/S
Signed-off-by: Rudrakh Panigrahi <rudrakh97@gmail.com>
|
@istio/technical-oversight-committee bumping this up. Thanks! |
ramaraochavali
left a comment
ramaraochavali
left a comment
There was a problem hiding this comment.
LGTM. @keithmattix WDYT?
| // In `ALLOW_ANY_DYNAMIC_DNS` mode, traffic to unknown destinations will be allowed via dynamic DNS resolution. | ||
| // This mode allows users that do not have all possible egress destinations registered through `ServiceEntry` configurations to still connect | ||
| // to arbitrary destinations. Client TLS settings can be configured for connections to such destinations. | ||
| ALLOW_ANY_DYNAMIC_DNS = 3; |
There was a problem hiding this comment.
I'm kind of confused how this will work; don't you need a service entry for dynamic dns anyway?
There was a problem hiding this comment.
@keithmattix Thanks for the comment!
Today, if you create a ServiceEntry with resolution DYNAMIC_DNS, it results in a DFP cluster for that wildcard hostname.
This proposal extends the same mechanism for a mesh-wide fallback. When outboundTrafficPolicy.mode = ALLOW_ANY_DYNAMIC_DNS, Istio should program a dedicated DFP cluster serving catch all requests (domain name *, analogous to PassthroughCluster in ALLOW_ANY).
There was a problem hiding this comment.
Honestly, I'm not very comfortable with the idea of DFP as a mesh wide fallback. The TLS SNI filter in particular is still alpha and having envoy resolve all DNS in the cluster with this mode just feels like confused deputy waiting to happen
There was a problem hiding this comment.
The TLS SNI filter in particular is still alpha
Are you referring to SNI Dynamic Forward Proxy? I wasn't thinking we will do toSNI Dynamic Forward Proxy here - rather when the mode is ALLOW_ANY_DYNAMIC_DNS and the traffic is TLS - just use PassthroughCluster mode and if it is non TLS - use HTTP Dynamic Forward Proxy with client TLS settings - this works similar to mesh call with cluster + DR defined.
Can you please explain more about confused deputy issue - definitely want to understand more to see if the above resolves or we need to rethink?
There was a problem hiding this comment.
The TLS SNI filter in particular is still alpha and having envoy resolve all DNS in the cluster with this mode just feels like confused deputy waiting to happen
Valid concern on the SNI filter being alpha, but this is an explicit opt-in only mode and the security posture is arguably better than ALLOW_ANY where Envoy blindly forwards to whatever IP the application resolved to. In this mode, DFP independently re-resolves via SNI/Host header, and while that re-resolution could be the "confused deputy" problem you are pointing to (ack on that), isn't it actually more secure?
There was a problem hiding this comment.
Even if we only do this for HTTP, the confused deputy issue still stands @ramaraochavali. And on the better vs worse security posture: first off, REGISTRY_ONLY was never a security boundary to begin with. The client application can bypass the sidecar in a number of ways (one of them being as simple as running with a specific UID), so users shouldn't rely on it for egress enforcement. I'd also contend that DFP on unmatched requests is actually less secure because even if you tried to use REGISTRY_ONLY as enforcement, you're poking a massive hole in it and not really blocking anything. Plus, a malicious client can now force envoy to do a DNS request to literally any domain (e.g an attacker controlled DNS server) just by putting the host in the host header or SNI. So if I put 169.254.169.254 in my host header, envoy will resolve it and send my request to Envoy's metadata server (that's the confused deputy part). And the mesh admin has no way to even stop it in this mode
keithmattix
left a comment
keithmattix
left a comment
There was a problem hiding this comment.
Need some discussion on security posture re: my last comment /cc @howardjohn
5 participants
Since DFP is now supported in sidecar mode (see istio/istio#58688) proposal is to introduce a
ALLOW_ANY_DYNAMIC_DNSmode for outbound traffic policy that uses DFP to route unknown traffic. This will enable users to apply TLS config to unknown traffic as well.Related usecase
Related issue: istio/istio#58244
fyi @ramaraochavali