Hi Dan, Thanks a lot for your response! Here is my thoughts about your questions inline.
* Should we include the link-local block, 169.254.0.0/16? It seems this is mostly used for DHCP discovery, so maybe it's not necessary (I think it's better to be overly restrictive here than overly permissive, given the security focus). It appears to me that link-local address is to allow machines to have an IP address on a network if they haven't been manually configured or DHCP services are not available. Therefore, I think link-local block should also be considered as private network. * Do we need to support IPv6 private and loopback blocks? Does Kudu support IPv6 in general? AFAIK, Kudu does not support IPv6 in general. And I think loopback block (local addresses: 127.0.0.0/8) should be considered as trusted subnet by default. * Are there subnets we're missing? Is this going to cause a lot of undue pain to users? Here you mean are we missing any subnets that should be considered as trusted by default, right? I cannot think more than the ones mentioned (private IPv4/IPv6 address, loopback address, link-local address). One thing to note is that users can always config the 'trusted-subnets' flag to add more subnets in case we miss some. It does not seem to be a huge pain to users from my perspective. But maybe others have more thoughts on this? Best, Hao On Wed, Apr 26, 2017 at 11:08 AM, Dan Burkert <[email protected]> wrote: > Hi Hao, > > First off, thanks for working on this. I think it's crucial to avoid the > bad reactions that a lot of other databases have been getting recently. > Secure by Default! > > I like the idea of a 'trusted-subnets' flag, which defaults to the private > and loopback address blocks. E.g. something along the lines of: > > DEFINE_string(trusted_subnets, " > 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16", > "Trusted subnetworks. Connections originating from outside of > these " > "networks must be authenticated, even if authentication is > not " > "otherwise required (e.g. --rpc-authentication=disabled)." > > I do have a couple of questions: > > * Should we include the link-local block, 169.254.0.0/16? It seems this > is > mostly used for DHCP discovery, so maybe it's not necessary (I think it's > better to be overly restrictive here than overly permissive, given the > security focus). > > * Do we need to support IPv6 private and loopback blocks? Does Kudu > support IPv6 in general? > > * Are there subnets we're missing? Is this going to cause a lot of undue > pain to users? > > - Dan > > On Tue, Apr 25, 2017 at 5:23 PM, Hao Hao <[email protected]> wrote: > > > Hi everyone, > > > > In the work of refusing from publicly routable IP addresses (KUDU-1875), > it > > would be useful to > > provide users a way to whitelist any 'trusted' but publicly IP address. > So > > that unauthenticated > > connections coming from those public IP addresses will not be rejected. > > > > One way I am proposing here, is to provide a Gflag that can take a list > of > > subnet (in CIDR notation). > > And consider those subnet as trusted and do not refuse any > unauthenticated > > connections. > > > > Please let me know your thoughts or if you have any alternatives in mind. > > Thanks a lot! > > > > Best, > > Hao > > >
