Thanks Jiangtao for the clarification. Ruslan, a gRPC client should be able to make a connection by specifying ip:port as a target name when creating a channel (e.g., grpc_secure_channel_create()), for instance https://github.com/grpc/grpc/blob/master/test/core/end2end/fixtures/h2_fakesec.cc#L70.
On Friday, September 14, 2018 at 2:37:11 AM UTC-7, Ruslan Nigmatullin wrote: > > We use it in production for workload-to-workload communication. TLS > certificate's CNAME contains an identity of the service and it is used > for mutual authentication (so said, hostname and ip address are not > directly part of the cname). > > We're planning to look at SPIFFE in the future and described > possibilities are definitely exciting. > > Thank you also for clarifying that ssl_target_name_overrides will > continue to be supported. It removes the concern from our side and > opens the path forward for potential careful migration to SPIFFE type > credentials in the future. > > On Thu, Sep 13, 2018 at 8:59 PM jiangtao via grpc.io > <[email protected] <javascript:>> wrote: > > > > Ruslan, > > > > I want to understand more of your use case on hostname override. Is it > used in testing? What is in the server's TLS certificate? Hostname or > server identity or server's IP address? > > > > For workload-to-workload communication, I suggest you use SPIFFE type > credentials in the gRFC, in such scenario, hostname verification is not > check (thus you don't need target_name override). Instead, there is a > custom server authorization callback, where client can decide whether > server is "good" based on server's credential chain and target name. You > can define whatever check you like, e.g., match IP address, revocation > check, or check whether server identity in server certificate is in some > ACL. > > > > Of course, if you still want to check hostname, but hostname in > certificate does not match the server address, you can still use > ssl_target_name_overrides as today in new TLS channel certificates format. > > > > Thanks, > > Jiangtao > > > > On Thursday, September 13, 2018 at 3:40:39 PM UTC-7, Ruslan Nigmatullin > wrote: > >> > >> Hi, > >> > >> I've read grpc-core a bit more and it looks like I've misunderstood > >> the interaction between resolver and authority used by TLS layer. It > >> looks like it's resolver's responsibility to provide the correct > >> authority for the given target (which is later going to be used for > >> initializing secure connector as server name). > >> > >> Though I can't find a way to specify server name in case of direct > >> gRPC connections by ip address and port (or "localhost" and port, > >> which is often used for its convenience) without using > >> "grpc.ssl_target_name_override". Can you advice, please? > >> > >> Though it's going slightly away from the topic of this discussion and > >> I'm fine if we've moving it out of this thread as it's not a change > >> compared to the existing world. (and therefore not a blocker for the > >> proposal) > >> > >> > >> On Thu, Sep 13, 2018 at 10:11 AM yihuaz via grpc.io > >> <[email protected]> wrote: > >> > > >> > 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]> 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/5362743d-3511-4d4c-ab0a-16c75e4391c0%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] <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/0ede1413-8520-474a-9d25-030cc08420af%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/3164efbf-fccb-46be-b099-b36660e7efa8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
