Hi Ruslan, Thanks for the comments.
Credential API's in gRPC core does not bind with any specific targets so I do not think we should introduce server names (or its orverride) into it. Liked you said, gRPC core auth stack also provides target-name override functionality, but it is mainly used for testing only (i.e., SSL hostname check) and from that regard, I also hesitate to include it into the surface credential API's. Regarding grpclb use case, in gRPC core, we also use a single credential object but create a different security connector for each connection to a particular backend, and the information about backend is provisioned via name resolver and load balancer (not from credential API's). Do you have other use cases that require target-name override to be present in credential API? On Wednesday, September 12, 2018 at 2:14:28 PM UTC-7, Ruslan Nigmatullin wrote: > > 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] <javascript:>> 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] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > 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/5362743d-3511-4d4c-ab0a-16c75e4391c0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
