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 <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/40a0dfe2-64c4-4f41-be9c-4964b76d55ec%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
