Proposal to add a new TLS credential API to support SPIFFE mutual TLS

[yih...@google.com]

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.

[iha...@netflix.com]

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.

[yih...@google.com]

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.

[jian...@google.com]

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.

[iha...@netflix.com]

Great, this all sounds good to me then!

[Ruslan Nigmatullin]

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?

> --
> 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 grpc-io+u...@googlegroups.com.
> To post to this group, send email to grp...@googlegroups.com.
> 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.

[yih...@google.com]

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? 

[Ruslan Nigmatullin]

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)

> To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/5362743d-3511-4d4c-ab0a-16c75e4391c0%40googlegroups.com.

[jian...@google.com]

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

[Ruslan Nigmatullin]

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.

> To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/0ede1413-8520-474a-9d25-030cc08420af%40googlegroups.com.

[yih...@google.com]

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.