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 <https://github.com/grpc/grpc/pull/16395>? 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/4fc3722b-e7a2-486a-9088-14277b46cd41%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
