From commits-return-24603-apmail-pulsar-commits-archive=pulsar.apache.org@pulsar.apache.org Fri Mar 15 16:03:36 2019
Return-Path:
X-Original-To: apmail-pulsar-commits-archive@minotaur.apache.org
Delivered-To: apmail-pulsar-commits-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id E1AFD1881A
for ; Fri, 15 Mar 2019 16:03:35 +0000 (UTC)
Received: (qmail 59563 invoked by uid 500); 15 Mar 2019 16:03:35 -0000
Delivered-To: apmail-pulsar-commits-archive@pulsar.apache.org
Received: (qmail 59509 invoked by uid 500); 15 Mar 2019 16:03:35 -0000
Mailing-List: contact commits-help@pulsar.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@pulsar.apache.org
Delivered-To: mailing list commits@pulsar.apache.org
Received: (qmail 59497 invoked by uid 99); 15 Mar 2019 16:03:35 -0000
Received: from ec2-52-202-80-70.compute-1.amazonaws.com (HELO gitbox.apache.org) (52.202.80.70)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Mar 2019 16:03:35 +0000
From: GitBox
To: commits@pulsar.apache.org
Subject: [GitHub] [pulsar] ivankelly commented on issue #3735: Implementing
authentication for Pulsar Functions
Message-ID: <155266581522.27730.1819253669421310516.gitbox@gitbox.apache.org>
Date: Fri, 15 Mar 2019 16:03:35 -0000
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
ivankelly commented on issue #3735: Implementing authentication for Pulsar Functions
URL: https://github.com/apache/pulsar/pull/3735#issuecomment-473344350
@jerrypeng
So mapping out the interactions here, yields the following sequence diagram.
![image](https://user-images.githubusercontent.com/54955/54443615-3fc78f00-4741-11e9-90b9-c0370ca0112a.png)
I think this can be similifed a fair bit.
First of all, service accounts are not needed, you can attached the secret directly to the stateful set. In fact, thats exactly what you are doing. service accounts are for pods to authenticate with k8s services. We're not doing that, and we don't need to do that for this implementation. It may be needed for vault at a later stage, but let's not make assumptions about how that'll be used until we have concretely worked out the flow for that.
Secondly, i don't think we need an interface for attaching the secret to the stateful set. Whatever the auth data is that we are passing in, we should assume it is secret, so if there is auth data, the **k8s runtime** should attach that as a secret. Then it is up to configureAuthenticationConfig to know how to do something with that authData. So we should move the attachment of the secret volume and the mount into the k8s runtime itself.
so the resulting sequence would look like
![image](https://user-images.githubusercontent.com/54955/54444803-c54c3e80-4743-11e9-9ae6-057a48651f31.png)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services