Hi! What's the state of current per-pod identity support? Is it still only EAP?
Best, On Monday, April 12, 2021 at 3:43:37 AM UTC+2 [email protected] wrote: > +Daniel Wong +Wanxin Yuan > 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/dd1af639-c7f5-44bc-a854-a2dab86fa301n%40googlegroups.com.
