From dev-return-98300-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Wed Sep 19 19:45:36 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 84055180621 for ; Wed, 19 Sep 2018 19:45:35 +0200 (CEST) Received: (qmail 80900 invoked by uid 500); 19 Sep 2018 17:45:34 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 80886 invoked by uid 99); 19 Sep 2018 17:45:33 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Sep 2018 17:45:33 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 37191C0E33 for ; Wed, 19 Sep 2018 17:45:33 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.398 X-Spam-Level: ** X-Spam-Status: No, score=2.398 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_LOCAL_NOVOWEL=0.5, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id yeiWLYOPGDfE for ; Wed, 19 Sep 2018 17:45:32 +0000 (UTC) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com [209.85.214.49]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 30CC35F46D for ; Wed, 19 Sep 2018 17:45:32 +0000 (UTC) Received: by mail-it0-f49.google.com with SMTP id h3-v6so9463068ita.2 for ; Wed, 19 Sep 2018 10:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BgWqUAxi90r4vzjNHjJpquNSJ+rEHDE42bQ6aeOjnJU=; b=PYp0D6FGjRufN7p2nLdFuGLk755NbWg/aTblxJwxqyZ07W6Dan7wHifGCXVy2CKaHP Q7+WEKjw7YqZbWaD1TgJOsRsaPXfsKUGF/UOY0H9edFMGCFRJ6+Lh+u6YgfLTXNKznaP zCe9IBWEDZWVtWwxOslvKtYGol9yLRg8mf69QU7zuZpsXM8LG7jIAb4/0B6gi4SxNCHh me5mGtedours8TBsjCJWvdsKfsZeZ0y4WibVErOmGauItQ4+jPZjGQZX6Rq7mRN3Fgkc LZv99zyP6O4ynQSNAgfNdUn8tr3WvT3/aK+1un1QBa40j4MGONzQsdg8MwDovA8oBur0 5chw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=BgWqUAxi90r4vzjNHjJpquNSJ+rEHDE42bQ6aeOjnJU=; b=ePwV9TdH54tKzvh0ZLYqnqPXqv/EJI1ZYrlXA2j0jkEM6sn1PzvXL8dApsy1YYbe8q 20daHAn5WXn3nFnXZ6IB2Eko1z/v1ov1J08qj2kQPUF+F5yPrhtS5pO3MxRwbhuLmyb+ j9MleLQ7gw40L5KlQmgKustE4rZsg/9oZnuE01TwAUkn4xOHbx7W4Ad/trtm9RqmjYPv 6Uqo5N1ILHuetTYH47V7Fzc+e2O6a0JoknHqzy3+C66qMcLnH+ETsPqMxzrG5TJPYlI6 LeexjzsHXR10haWKmuDYNNj1HQKbAB0KwkZUIKEAXA1GOPmmNpjwNtwyIStQ4CQXAnBg QdsQ== X-Gm-Message-State: APzg51C0moUTIXhgtfVHXkIBqKfOlCSFSb3rpOBg7KhYHekc/wNDPVQ/ 6MfqBN33mf65sNja71IrOnaAq0POgP+M0LNlP2DhmDfK X-Google-Smtp-Source: ANB0Vdbu2kdRn05jYzADD053i2l0G96ydgCgR8QHFqlj0zyqBTe9jYERGSdBhuZ/LipadNIv4wzsR/g+lEi0BjFXkig= X-Received: by 2002:a24:8203:: with SMTP id t3-v6mr20858780itd.150.1537379131234; Wed, 19 Sep 2018 10:45:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Dagostino Date: Wed, 19 Sep 2018 13:45:19 -0400 Message-ID: Subject: Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate To: dev@kafka.apache.org Content-Type: multipart/alternative; boundary="000000000000009ee505763cf96a" --000000000000009ee505763cf96a Content-Type: text/plain; charset="UTF-8" Hi Tyler. This KIP is written such that the sever (broker) specifies a session lifetime to the client, and then the client will re-authenticate at a time consistent with that with whatever credentials it has when the re-authentication kicks off. You could specify a low max session lifetime on the broker, but then you have to make sure the client refreshes its credentials at that rate (and there are refresh-related configs for kerberos to helkp you do that, such as sasl.kerberos.ticket.renew.window.factor). But whether this would solve your problem or not I don't know. It certainly won't allow you to react when the scenario occurs, but it if your session lifetime and credential refresh window are short enough you would end up reacting relatively soon thereafter -- but again, my knowledge of Kerberos and what is exactly going on in your situation is limited/practically zero. I'm in the process of getting the PR into shape, and hopefully it will be ready in the next week or so -- you could of course try it out at that time and see. Ron On Wed, Sep 19, 2018 at 1:26 PM Tyler Monahan wrote: > Hello, > > I have a rather odd issue that I think this KIP might fix but wanted to > check. I have a kafka setup using SASL/Kerberos and when a broker dies in > aws a new one is created using the same name/id. The Kerberos credentials > however are different on the new instances and existing > brokers/consumers/producers continue to try using the stored credentials > for the old instance on the new instance which fails until everything is > restarted to clear out stored credentials. My understanding is this KIP > would make it so Re-Authenticate will clear out bad stored credentials. I > am not sure if the re-authentication process would kick of when something > fails with bad credential errors though. > > Tyler Monahan > --000000000000009ee505763cf96a--