+Daniel Wong <[email protected]> +Wanxin Yuan <[email protected]> ALTS with per-pod identity is available for EAP. Please contact Daniel and Wanxin, if you want to try it out.
Thanks, Jiangtao On Sat, Apr 10, 2021 at 6:08 PM James Duncan <[email protected]> wrote: > 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 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/0aa92bb7-c21b-4206-91d0-ea3749ae27aen%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/0aa92bb7-c21b-4206-91d0-ea3749ae27aen%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_g23Zgo%2BxRzfr8Wj8EKARzJ8j0zNBSNPsdZYFciAe%2BuPw%40mail.gmail.com.
