I still don't see ALTS listed as as use case for Workload Identity <https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to> Is this still EAP? I am getting recv_buffer is nullptr in alts_tsi_handshaker_handle_response() in my service running in GKE and I suspect it can't reach the handshaker? Any pointers would be helpful Thanks On Wednesday, May 25, 2022 at 2:43:58 PM UTC-4 Michał Załęcki wrote:
> 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/72e06633-9fcd-481d-b3b8-cd12d52ec9f7n%40googlegroups.com.
