I would be interested in ALTS outside of GCP. Are there any plans to make a public version of the other components/services required to run ALTS in a private network?
On Tuesday, May 29, 2018 at 6:53:10 PM UTC-4, Ruslan Nigmatullin wrote: > > Hi Jiangtao, > > Sorry for the delay, we're ready to move forward. Are you still interested > in having a video conference to discuss it? > > On Monday, April 23, 2018 at 5:28:25 PM UTC-7, Ruslan Nigmatullin wrote: >> >> Hi Jiangtao, >> >> Thanks for the suggestion, we will have a meeting internally to discuss >> it and I'll follow up after it. >> >> On Friday, April 20, 2018 at 10:28:47 PM UTC-7, Jiangtao Li wrote: >>> >>> Hi Ruslan, >>> >>> We just had a meeting today to discuss this. We probably want to >>> understand your use case better. >>> >>> ALTS is a whole package: key exchange, record protocol, key management, >>> and trust model. It seems strange to have non-ALTS handshake, but use ALTS >>> record protocol. >>> >>> On the other hand, we are interested in developing gRPC SSL stack using >>> handshaker service model. >>> 1. gRPC code that talks to SSL handshaker service. This will have shared >>> code with gRPC ALTS stack. >>> 2. Handshaker service that conducts TLS 1.2 and/or 1.3 handshake. >>> 3. Zero-copy frame protector that implement TLS record protocol. This >>> will not use OpenSSL BIO API, instead, will directly call OpenSSL/BoringSSL >>> AEAD crypto API. >>> >>> We probably have limit bandwidth on implementation. You probably can >>> implement item 2. whereas we can implement item 1 first. >>> >>> Feel free to schedule a video conference with us. >>> >>> Thanks, >>> Jiangtao >>> >>> >>> On Thu, Apr 19, 2018 at 4:23 PM 'Ruslan Nigmatullin' via grpc.io < >>> [email protected]> wrote: >>> >>>> Thanks for you response, >>>> >>>> Please let us know if we (Dropbox) can help in any way with this >>>> decision or with implementing any functionality/tests for alts to ease the >>>> process. >>>> >>>> On Friday, March 30, 2018 at 4:51:43 PM UTC-7, [email protected] >>>> wrote: >>>>> >>>>> So far ALTS is for GCP use only. Let me discuss with my management to >>>>> see whether we can provide an easy interface to use "pluggable" >>>>> handshaker >>>>> service. If so, we may expose API to choose either google default >>>>> handshaker service or pluggable handshaker service. Google default >>>>> handshaker service will check GCP environment and hardcode google >>>>> metadata >>>>> server address, whereas pluggable handshaker service can run on any >>>>> platforms and use any handshaker service address. >>>>> >>>>> As for local identity, it is not set in gRPC stack currently. We could >>>>> set through credential options. Again, this is related to whether we want >>>>> to open up pluggable handshaker service. >>>>> >>>>> >>>>> On Friday, March 30, 2018 at 12:30:35 PM UTC-7, Ruslan Nigmatullin >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi Jiangtao, >>>>>> >>>>>> On Thursday, March 29, 2018 at 10:54:22 AM UTC-7, [email protected] >>>>>> wrote: >>>>>>> >>>>>>> Hi Ruslan, >>>>>>> >>>>>>> ALTS is not ready for public consumption yet. We could expose ALTS >>>>>>> to early access customers. >>>>>>> >>>>>> >>>>>> Thanks for clarifying, we don't have immediate plans to use ALTS in >>>>>> our production setup but we're evaluating if it is an option in mid/long >>>>>> term. >>>>>> >>>>>> >>>>>>> Note that at this point, ALTS is for use inside GCP, such as >>>>>>> authentication between two workloads running on GCP or for faster >>>>>>> access of >>>>>>> Google cloud services on GCP. >>>>>>> >>>>>>> So far we do not support ALTS outside GCP. Of course, you can write >>>>>>> your own handshaker service and plug in whatever handshake protocol you >>>>>>> want, see handshaker proto ( >>>>>>> https://github.com/grpc/grpc-java/blob/master/alts/src/main/proto/handshaker.proto), >>>>>>> >>>>>>> and use ALTS gRPC code for record protocol. >>>>>>> >>>>>> >>>>>> Thanks, this was a direction I was looking into due to the following >>>>>> points: >>>>>> 1. All handshaking logic is kept in single binary, few examples: >>>>>> monitoring, rate limiting, cert rotation, session tickets, etc >>>>>> 2. Implementation of ALTS record protocol is ~2x more efficient than >>>>>> tls-based implementations (e.g. boringssl-based grpc-core), both for cpu >>>>>> and memory >>>>>> >>>>>> Though it looks like that at least some implementations deny ability >>>>>> to use ALTS outside of GCP environment (e.g. grpc-go one [1], ability to >>>>>> disable was removed by [2]). >>>>>> Are you comfortable with us (re)adding an ability to explicitly >>>>>> disable this check from code? >>>>>> >>>>>> We may also need to expose an ability to specify local identity (it's >>>>>> already part of HandshakerService API, so it's only grpc library >>>>>> change), >>>>>> is it okay? >>>>>> >>>>>> >>>>>>> Let us know if you are interested in using ALTS on GCP, so that we >>>>>>> may give you early access. >>>>>>> >>>>>>> >>>>>> 1. >>>>>> https://github.com/grpc/grpc-go/blob/master/credentials/alts/alts.go#L136 >>>>>> 2. https://github.com/grpc/grpc-go/pull/1931 >>>>>> >>>>>>> On Tuesday, March 27, 2018 at 11:49:34 AM UTC-7, Ruslan Nigmatullin >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> We're evaluating the possibility of using ALTS instead of TLS in >>>>>>>> our internal infrastructure for visibility and performance reasons. >>>>>>>> >>>>>>>> How ALTS support is positioned from gRPC perspective? Is it GCP >>>>>>>> implementation detail or you're supporting other companies in using it? >>>>>>>> >>>>>>>> We may need to expose extra API for configuring credentials (e.g. >>>>>>>> specifying local identity significantly simplifies migration process >>>>>>>> and >>>>>>>> it's already exposed in handshake api). Are you comfortable with it? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ruslan >>>>>>>> >>>>>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "grpc.io" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/grpc-io/FRiBpXucIRk/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at https://groups.google.com/group/grpc-io. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/grpc-io/8817d1c8-475e-47f1-ab15-951f764a3975%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/grpc-io/8817d1c8-475e-47f1-ab15-951f764a3975%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/56eec056-d844-4949-acd6-4208215e2eae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
