On Tuesday, March 24, 2020 at 9:02:33 AM UTC-7 Jiangtao Li wrote: > 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. >
I'm sorry to bump such an old thread, but this is the only reference I can find to the combination of ALTS with Workload Identity. Are there any updates on this feature that you may be able to provide, or perhaps a bug/ticket I can follow along on? Thanks! -James 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/0aa92bb7-c21b-4206-91d0-ea3749ae27aen%40googlegroups.com.
