New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for dns name as a field in NetworkPolicyPeer and the application of that #56901

Closed
phsiao opened this Issue Dec 6, 2017 · 8 comments

Comments

Projects
None yet
5 participants
@phsiao
Contributor

phsiao commented Dec 6, 2017

/kind feature

Today NetworkPolicyPeer supports ipBlock, namespaceSelector, and podSelector. This leaves one use case that is fairly common for dns name-based restrictions. I think we should support that by having a way to express peers for both ingress and egress via dns domain name.

/sig network

@phsiao

This comment has been minimized.

Show comment
Hide comment
@phsiao
Contributor

phsiao commented Dec 6, 2017

@phsiao

This comment has been minimized.

Show comment
Hide comment
@phsiao

phsiao Dec 6, 2017

Contributor

Some context in #22469.

Contributor

phsiao commented Dec 6, 2017

Some context in #22469.

@phsiao phsiao changed the title from Add support for dns name as a field in NetworkPolicyPeer and the use of that to Add support for dns name as a field in NetworkPolicyPeer and the application of that Dec 6, 2017

@cmluciano

This comment has been minimized.

Show comment
Hide comment
@cmluciano

cmluciano Dec 7, 2017

Member

We briefly discussed DNS selection in #50453. The reason why we did not move forward is because we would need an HTTP proxy.

Member

cmluciano commented Dec 7, 2017

We briefly discussed DNS selection in #50453. The reason why we did not move forward is because we would need an HTTP proxy.

@phsiao

This comment has been minimized.

Show comment
Hide comment
@phsiao

phsiao Dec 7, 2017

Contributor

Had a chat with @cmluciano, there are a two potential issues with supporting DNS name.

  1. DNS name and its resolution is "static", but the connection may not be. For example, a http server can decide to redirect based on Host, and the layer 3/4 network policy controller logic would not be able to follow that. As a result it becomes a usability problem.
  2. Dynamic DNS entries. Some DNS name can return different IP based on IP-sharding, geo-fencing, or just randomization, and it is a functional breakage if the pod and the network policy controller gets different results.
Contributor

phsiao commented Dec 7, 2017

Had a chat with @cmluciano, there are a two potential issues with supporting DNS name.

  1. DNS name and its resolution is "static", but the connection may not be. For example, a http server can decide to redirect based on Host, and the layer 3/4 network policy controller logic would not be able to follow that. As a result it becomes a usability problem.
  2. Dynamic DNS entries. Some DNS name can return different IP based on IP-sharding, geo-fencing, or just randomization, and it is a functional breakage if the pod and the network policy controller gets different results.
@cmluciano

This comment has been minimized.

Show comment
Hide comment
Member

cmluciano commented Dec 8, 2017

@redbaron

This comment has been minimized.

Show comment
Hide comment
@redbaron

redbaron Dec 11, 2017

Contributor

DNS whitelisting does't require HTTP proxy if same agent can see both DNS requests and IP traffic.

In kubernetes world that for instance can be a kube-proxy acting as DNS interceptor (or as an explicitly configured DNS server via kubelet), which then performs DNS resolution, observes response and open iptables rules before passing response to a POD.

iptables rules should include every A and AAAA record returned in the response and can be implemented using ipset with entry ttl being response TTL + 10 seconds (configurable).

Implemented like that, it can support DNS whitelisting for arbitrary protocols, not only TCP.

Contributor

redbaron commented Dec 11, 2017

DNS whitelisting does't require HTTP proxy if same agent can see both DNS requests and IP traffic.

In kubernetes world that for instance can be a kube-proxy acting as DNS interceptor (or as an explicitly configured DNS server via kubelet), which then performs DNS resolution, observes response and open iptables rules before passing response to a POD.

iptables rules should include every A and AAAA record returned in the response and can be implemented using ipset with entry ttl being response TTL + 10 seconds (configurable).

Implemented like that, it can support DNS whitelisting for arbitrary protocols, not only TCP.

@thockin

This comment has been minimized.

Show comment
Hide comment
@thockin

thockin Jan 6, 2018

Member

I really don't think we want to impose DNS refreshing on implementations of NetworkPolicy without a bunch of REALLY REALLY good use cases that just CAN NOT be solved any other way. Do we have such use cases?

Member

thockin commented Jan 6, 2018

I really don't think we want to impose DNS refreshing on implementations of NetworkPolicy without a bunch of REALLY REALLY good use cases that just CAN NOT be solved any other way. Do we have such use cases?

@thockin thockin closed this Jan 6, 2018

@redbaron

This comment has been minimized.

Show comment
Hide comment
@redbaron

redbaron Jan 7, 2018

Contributor

@thockin AFAIK PCI compliance requires DNS whitelisting solution to be on the path to the internet.

Contributor

redbaron commented Jan 7, 2018

@thockin AFAIK PCI compliance requires DNS whitelisting solution to be on the path to the internet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment