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]> 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]. > 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/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/CALfB5KxQV_33sn_%3D6Q1Ag%2BKemWFFr2D2K6UWXa8O-wJZnXTdhA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
