On Mon, Apr 8, 2019, at 06:38, Sönke Liebau wrote:
> Hi Colin,
>
> quick summary up front: I totally agree, and always have! I think we
> misunderstood each other a little :)
> I was never really opposed the idea of restricting which ACL features can
> be used, I was just opposed to doing it
Hi Colin,
quick summary up front: I totally agree, and always have! I think we
misunderstood each other a little :)
I was never really opposed the idea of restricting which ACL features can
be used, I was just opposed to doing it specifically for this change, while
not introducing real
On Thu, Apr 4, 2019, at 01:52, Sönke Liebau wrote:
> Hi Colin,
>
> I agree, we need to have a way of failing incorrect ranges server-side,
> I'll amend the KIP and look into that. I think INVALID_REQUEST should fit
> fine, afaik we can send a message along with that code, so that could
> explain
Hi Colin,
I agree, we need to have a way of failing incorrect ranges server-side,
I'll amend the KIP and look into that. I think INVALID_REQUEST should fit
fine, afaik we can send a message along with that code, so that could
explain the actual reason.
Regarding prohibiting these ACLs from being
Hi Sönke,
Maybe a reasonable design here would be to not allow creating ACLs based on ip
ranges and subnets unless the inter-broker protocol setting has been upgraded.
If an upgrade is done correctly, the IBP should not be upgraded until all the
brokers have been upgraded, so there shouldn't
All,
as this thread has now been dormant for about three months again I'll am
willing to consider the attempt at looking at a larger versioning scheme
for ACLs as failed.
I am away for a long weekend tomorrow and will start a [VOTE] thread on
implementing this as is on Monday, as I personally
Just a quick bump, as this has been quiet for a while again.
On Tue, Jan 8, 2019 at 12:44 PM Sönke Liebau
wrote:
> Hi Colin,
>
> thanks for your response!
>
> in theory we could get away without any additional path changes I
> think.. I am still somewhat unsure about the best way of addressing
Hi Colin,
thanks for your response!
in theory we could get away without any additional path changes I
think.. I am still somewhat unsure about the best way of addressing
this. I'll outline my current idea and concerns that I still have,
maybe you have some thoughts on it.
ACLs are currently
Hi Sönke,
One path forward would be to forbid the new ACL types from being created until
the inter-broker protocol had been upgraded. We'd also have to figure out how
the new ACLs were stored in ZooKeeper. There are a bunch of proposals in this
thread that could work for that-- I really hope
This has been dormant for a while now, can I interest anybody in chiming in
here?
I think we need to come up with an idea of how to handle changes to ACLs
going forward, i.e. some sort of versioning scheme. Not necessarily what I
proposed in my previous mail, but something.
Currently this fairly
Picking this back up, now that KIP-290 has been merged..
As Colin mentioned in an earlier mail this change could create a
potential security issue if not all brokers are upgraded and a DENY
Acl based on an IP range is created, as old brokers won't match this
rule and still allow requests. As I
Technically I absolutely agree with you, this would indeed create
issues. If we were just talking about this KIP I think I'd argue that
it is not too harsh of a requirement for users to refrain from using
new features until they have fully upgraded their entire cluster. I
think in that case it
There are still some problems with compatibility here, right?
One example is if we construct a DENY ACL with an IP range and then install it.
If all of our brokers have been upgraded, it will work. But if there are some
that still haven't been upgraded, they will not honor the DENY ACL,
Hi all,
I'd like to readopt this KIP, I got a bit sidetracked by other stuff
after posting the initial version and discussion, sorry for that.
I've added IPv6 to the KIP, but decided to forego the other scope
extensions that I mentioned in my previous mail, as there are other
efforts underway in
Hi Manikumar,
you are right, 5713 is a bit ambiguous about which fields are considered in
scope, but I agree that wildcards for Ips are not necessary when we have
ranges.
I am wondering though, if we might want to extend the scope of this KIP a
bit while we are changing acl and authorizer
Hi,
They are few deployments using IPv6. It is good to support IPv6 also.
I think KAFKA-5713 is about adding regular expression support to resource
names (topic. consumer etc..).
Yes, wildcards (*) in hostname doesn't makes sense. Range and subnet
support will give us the flexibility.
On Thu,
Hi Manikumar,
the current proposal indeed leaves out IPv6 addresses, as I was unsure
whether Kafka fully supports that yet to be honest. But it would be
fairly easy to add these to the proposal - I'll update it over the
weekend.
Regarding KAFKA-5713, I simply listed it as related, since it is
Hi,
1. Do we support IPv6 CIDR/ranges?
2. KAFKA-5713 is mentioned in Related JIRAs section. But there is no
mention of wildcard support in the KIP.
Thanks,
On Thu, Feb 1, 2018 at 4:05 AM, Sönke Liebau <
soenke.lie...@opencore.com.invalid> wrote:
> Hey everybody,
>
> following a brief inital
Hey everybody,
following a brief inital discussion a couple of days ago on this list
I'd like to get a discussion going on KIP-252 which would allow
specifying ip ranges and subnets for the -allow-host and --deny-host
parameters of the acl tool.
The KIP can be found at
19 matches
Mail list logo
