Mahmoud, Thanks much for your interests in ALTS. Right now ALTS only supports per node identity. We will be able to support per-pod identity in ALTS very soon, to be aligned with workload identity.
Thanks, Jiangtao On Tue, Mar 24, 2020 at 7:16 AM <[email protected]> wrote: > Hi, > > we recently started to try out ALTS in our GCP environment with two grpc > services written in Go. > We successfully could bootstrap our setup with the examples provided in [1] > . > From our experience ALTS is very handy and works as expected. Because we > are fully in GCP ALTS is currently internally discussed to replace TLS as a > whole. > But we have notice a unexpected behavior during our work with ALTS. We > have a GKE cluster where we have enabled Workload identity [2]. > We have created a pod with a Kubernetes service account (KSA) and bound it > to a Google service account (GSA) via an IAM policy described in the docs. > In general when ever the pod talks to a GCP API the pod authenticates with > the GSA. But we have noticed that a service with ALTS server retrieves not > the GSA but > the service account of the underlying compute instance which is quite > unfortunate because this means that all pod in a GKE cluster share the same > identity. > Our test setup is pasted below. We have basically wrapped > alts.NewServerCreds to log out the field of alts.AuthInfo what we get in > the logs are: > > 2020-03-24 12:34:17.000 CET { "msg": "ATLS server AuthInfo. > PeerServiceAccount: k8s-main@<omitted>.iam.gserviceaccount.com", "level": > "info" } > 2020-03-24 12:34:17.000 CET { "msg": "ATLS server AuthInfo. > LocalServiceAccount: k8s-test@<omitted>.iam.gserviceaccount.com", > "level": "info" } > > > Just to be clear the service accounts in the logs (k8s-main and k8s-test) > are the GCE service account and the pod has a totally different GSA via > workload identity. > > We understand that ALTS does not have a stable API yet but because of this > we would appreciate of you could consider support workload identity of GKE > in the future. > This would give ALTS a much bigger user case for a lot of GCP users. > And speaking of officially releasing a stable ALTS API are there any plans > or timelines for that yet? > > Thanks, > Mahmoud Azad > > > > > Appendix: Test code > > > func setupALTSGrpcCreds() grpc.ServerOption { > > serverCreds := alts.NewServerCreds(alts.DefaultServerOptions()) > wrappedTransportCredentials := transportCredsWrapper{wrapped: serverCreds} > return grpc.Creds(wrappedTransportCredentials) > > } > > > type transportCredsWrapper struct { > wrapped credentials.TransportCredentials > } > > func (t transportCredsWrapper) ClientHandshake(ctx context.Context, addr > string, rawConn net.Conn) (net.Conn, credentials.AuthInfo, error) { > return t.wrapped.ClientHandshake(ctx, addr, rawConn) > } > > func (t transportCredsWrapper) ServerHandshake(rawConn net.Conn) > (net.Conn, credentials.AuthInfo, error) { > con, authInfo, err := t.wrapped.ServerHandshake(rawConn) > if err != nil { > log.Warnf("got error in transportCredsWrapper: %s", err) > return nil, nil, err > } > > altsAuthInfo, ok := authInfo.(alts.AuthInfo) > if !ok { > return nil, nil, errors.New("server-side auth info is not of type > alts.AuthInfo") > } > > log.Infof("ATLS server AuthInfo. LocalServiceAccount: %s", > altsAuthInfo.LocalServiceAccount()) > log.Infof("ATLS server AuthInfo. PeerServiceAccount: %s", > altsAuthInfo.PeerServiceAccount()) > > return con, authInfo, err > } > > [...] > > > [1] > https://github.com/grpc/grpc-go/tree/master/examples/features/encryption/ALTS > > [2] > https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity > > On Tuesday, 21 January 2020 18:54:18 UTC+1, Cyrus Katrak wrote:Thanks. > >> I'm investigating the option space for securing the authenticity and >> privacy of gRPC transport connections in a service oriented architecture >> running outside of GCP. >> >> I've narrowed in on a technical solution that looks a lot like the >> marriage of SPIFFE and ALTS, with some necessary differences. Other threads >> in this mailing list seem to suggest that despite the ALTS implementation >> being included in the open source grpc repos, it remains specific to >> Google, experimental, and unsupported. >> >> I wanted to ask and understand: >> - The level of interest from the community of having a relatively open >> and extensible identity / authenticity / confidentiality solution for grpc. >> - What if anything is already underway in the community along these lines. >> - What Google's roadmap for ALTS+gRPC is. >> >>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "grpc.io" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/grpc-io/RSYaZc18O_M/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/ab595f8a-8e79-46fa-a25d-d06fde3d3b3f%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/ab595f8a-8e79-46fa-a25d-d06fde3d3b3f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CACcm8_hRSwzfNAzd-cpweTdqD8PUGiYXM8LCGorEE01RAcvE3Q%40mail.gmail.com.
