Golang gRPC credentials API allows creating clones of the credentials and override server names. It's useful in couple of scenarios, namely grpclb and having single "original" credential object shared across all clients/servers in the process (to actually reload & parse certs once per process, instead of once per every client). Current grpc-core API assumes that server name for grpclb is overriden via channel arguments instead of explicit credentials API.
Is there a value in having similar interface in grpc-core and wrapped languages? On Fri, Sep 7, 2018 at 5:18 PM ihaken via grpc.io <[email protected]> wrote: > > Great, this all sounds good to me then! > > On Friday, September 7, 2018 at 9:20:30 AM UTC-7, [email protected] wrote: >> >> Thanks Yihua for clarification. >> >> TLS server authorization is client-side enhancement. It is that client >> checks whether server is authorized to run the service (based on target name >> and server's identity). >> >> In the near future, we will propose and implement server-side client >> authorization check (aka, RPC Security Policy) using RBAC for gRPC. In this >> scenario, on each RPC request, server can check whether client is authorized >> to access certain RPC method based on client identity in channel credentials >> and call credentials, using role-based access control. More details coming >> soon. >> >> On Friday, September 7, 2018 at 9:04:33 AM UTC-7, [email protected] wrote: >>> >>> Thanks for your response. >>> >>> I think there is a confusion on the term - "server authorization check" >>> (its another name is "secure naming check", but we decided to stick with >>> the former). Note that it is one-side check and will be performed only at >>> the client side to authorize the server (NOT the other way around) so, >>> there is no need to have "TLS channel authorization check". In other >>> words, it will play the same role as the current verify_peer_callback and >>> will eventually supersede your PR. >>> >>> On Thursday, September 6, 2018 at 10:46:25 PM UTC-7, [email protected] >>> wrote: >>>> >>>> This all looks quite good to me. In particular the credential reloading >>>> component would be really helpful for us; at the moment we've been tearing >>>> down and reconstructing channels to handle credential reloading as needed. >>>> This is definitely a lot better. A couple of comments to add: >>>> >>>> The credential reload APIs appear as though they would work just as well >>>> on server or client side. On the other hand the "TLS server authorization >>>> check" is an server-specific enhancement. At the risk of scope creep, >>>> would it be worth generalizing this as a general mechanism to perform a >>>> "TLS channel authorization check" in such a way that would supersede the >>>> PR I was working on for the client-side verify_peer_callback? The >>>> mechanism seems analogous so I'm just wondering if it's a >>>> two-birds-with-one-stone situation. >>>> >>>> Secondly: >>>>> >>>>> Regarding grpc_tls_ctx_customize_config, the config is used when a caller >>>>> wants to >>>>> configure an underlying TLS context with customized primitives. For >>>>> example, there could >>>>> be a use case in which raw private keys are not directly accessible >>>>> (e.g., hardware-backed) to a caller, >>>>> but private key methods (e.g., “Sign” functions) are, in which case the >>>>> config provides a means >>>>> to customize an TLS context with an SSL_PRIVATE_KEY_METHOD object and >>>>> associated signing algorithms. >>>> >>>> >>>> I just want to throw in my support for this foresight. We've recently been >>>> adding in support for hardware-backed private keys in other contexts >>>> (mostly for REST based use-cases). We haven't hit a need to integrate this >>>> with gRPC in languages other than Java and Go, but I see a desire for it >>>> in our ecosystem coming down the pipeline in the not-too-distant future. >>>> >>>> On Wednesday, September 5, 2018 at 2:21:13 PM UTC-7, [email protected] >>>> wrote: >>>>> >>>>> I just opened a gRFC that proposes to add a new TLS credential API with >>>>> the purpose of supporting SPIFFE mutual TLS: >>>>> https://github.com/grpc/proposal/pull/98. >>>>> >>>>> Please keep any discussion on this thread. > > -- > 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/40a0dfe2-64c4-4f41-be9c-4964b76d55ec%40googlegroups.com. > 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/CALfB5KwuinmCnmteioeCBhty1Ga0fcAsXX%3DDKisoahXVp-f%3DmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
